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Preface 


The VAX/VMS System Manager's Reference Manual provides system managers 
with the concepts and procedures for performing routine system management 
operations on VAX/VMS systems. This manual is designed to 

• Describe the tasks involved in managing, operating, and maintaining a 
VAX/VMS system 

• Provide general information on day-to-day operating procedures 

• Introduce utilities and commands used to perform specific system 
management functions 

This manual is not intended to be a complete one-volume reference source 
of information. Utilities and commands used to perform specific system 
management and operating tasks are described in detail in the individual 
VAX/VMS utility reference manuals, and in the VAX/VMS DCL Dictionary . 
This manual does not include information on configuring and managing 
VAXcluster systems; for that information, refer to the Guide to VAXclusters. 


Intended Audience 

This manual addresses experienced users of the VAX/VMS system who must 
perform the functions of a system manager or operator. 


Structure of This Document 

The VAX/VMS System Manager's Reference Manual is divided into two parts, 

each covering a related group of system management tasks: 

• Part I, Setting Up the System , describes the tasks and tools necessary to 
prepare a VAX/VMS operating system for daily operation. This section 
includes discussions on making site-specific modifications to VAX/VMS, 
performing system startup and shutdown, setting up and maintaining user 
accounts, and allocating system resources. 

• Part II, Maintaining the System , describes the tasks and tools necessary 
to maintain and routinely operate the system, and builds upon concepts 
presented in Part I. This section includes discussions on maintaining 
public files and volumes, installing images as known images, maintaining 
batch and output queues, using error and operator logging facilities, and 
modifying system parameters. 

Appendix A describes special operations for the VAX-11/750 processor. 

Appendix B provides information about the Computer Interconnect (Cl), 

associated error messages, and corrective procedures. 
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Associated Documents 

For general background information about the system, see the Introduction to 
VAX/VMS. 

For information on system installation and upgrade procedures, consult the 
Guide to VAX/VMS Software Installation and the software installation booklets 
for your VAX processor. 

For information on creating and maintaining volumes using the volume 
shadowing option, refer to the VAX/VMS Volume Shadowing Manual. 

For hardware operating instructions, refer to the appropriate hardware 
manual. 

For managing network operations, refer to the VAX/VMS Networking Manual. 

For configuring and managing VAXclusters, refer to the Guide to VAXclusters. 

The following documents provide important system management reference 
and supplemental information: 

• VAX/VMS DCL Dictionary 

• The VAX/VMS Utility Reference Manuals 

• VAX/VMS System Messages and Recovery Procedures Reference Manual 

• Guide to VAX/VMS Disk and Magnetic Tape Operations 

• Guide to VAX/VMS Performance Management 


Conventions Used in This Document 


Convention 

EM] 


|CTRL/x| 


$ SHOW TIME 
05-JUN-1986 11:55:22 

$ TYPE MYFILE.DAT 


file-spec, . . . 


Meaning 

A symbol with a one- to six-character 
abbreviation indicates that yo u pr ess a key 
on the terminal, for example, I RET| . 

The phrase CTRL/x indicates that you 
must press the key labeled CTRL while you 
simultaneously press another key, for example, 
CTRL/C, CTRL/Y, CTRL/O. 

Command examples show in blackletters all 
output lines or prompting characters that the 
system prints or displays. All user-entered 
commands are shown in red letters. 

A vertical series of periods, or ellipsis, means 
either that not all the data that the system 
would display in response to the particular 
command is shown or that not all the data a 
user would enter is shown. 

Horizontal ellipsis indicates that additional 
parameters, values, or information can be 
entered. 
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Convention 

Meaning 

[logical-name] 

Square brackets indicate that the enclosed item 
is optional. (Square brackets are not, however, 
optional in the syntax of a directory name in a 
file specification or in the syntax of a substring 
specification in an assignment statement.) 

quotation marks 
apostrophes 

The term quotation marks is used to refer 
to double quotation marks ("). The term 
apostrophe (') is used to refer to a single 
quotation mark. 
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New and Changed Features 


The Version 4.4 VAX/VMS System Manager's Reference Manual includes 
information on the new and changed features added to the VAX/VMS 
operating system since Version 4.0. This manual was previously a handbook 
entitled Guide to VAX/VMS System Management and Daily Operations. The 
major changes and enhancements to the documentation are found in the 
following sections: 

• Section 2—Includes additional information on standalone BACKUP. 

• Section 4—Includes the procedure for performing an emergency shutdown 
with CRASH on a VAX 8600 or VAX 8650 system. 

• Section 5—Includes the following new information: 

- Procedure for recovering lost files in the SYSLOST directory 

- Procedure for adding a secondary password to a UAF record 

- New Authorize Utility AUTOLOGIN flag for restricting login functions 

• Section 8—New section on installing execute-only images; the image 
activator allows execution of images to which the caller has EXECUTE but 
not READ access. 

• Section 9—This section has undergone major revision and reorganization 
for Version 4.4. The major changes to the batch/print facility are listed as 
follows: 

- New /RESTART qualifier for the START/QUEUE/MANAGER 
command, which causes the queue manager to automatically restart on 
recovery from a job controller abort. 

- Additional information on holding and releasing jobs including the 
new /NOAFTER qualifier of the SET QUEUE/ENTRY command. 
Specifying this qualifier immediately releases a job held by previously 
specifying the /AFTER qualifier. 

- New tables listing the qualifiers used to specify queue attributes. 

- New figures displaying the formats for job and file separation pages. 

- Additional information and examples on using device control library 
modules to set up print devices for special printer functions. 

- New /[NO]PAGE—SETUP qualifier for the DEFINE/FORM command 
specifies one or more device control library modules to set up the print 
device to perform special printer functions at the beginning of each 
page. 

- New /FORM_MOUNTED qualifier for the INITIALIZE/QUEUE, 
START/QUEUE, and SET QUEUE commands replaces the /FORM 
qualifier. This qualifier associates the paper stock of the form with that 
of the output queue. 

- New section describing how to change the systemwide default form. 

- New /DEFAULT=FORM keyword for the INITIALIZE/QUEUE, 

START/QUEUE, and SET QUEUE commands allows you to specify a 
queue-specific default form type. 
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New and Changed Features 


- Additional documentation on controlling page and line overflow 
including the /[NOJPASSALL qualifier. Specifying /PASSALL with 
the PRINT command sends I/O to the device driver with formatting 
suppressed. 

- New /[NO]RECORD_BLOCKING qualifier for the START/QUEUE, 
INITIALIZE/QUEUE, and SET QUEUE commands determines whether 
the symbiont can block together output records for transmission to the 
output device. 

• Section 11—Includes the following new information: 

- New configuration parameters added to SYS$SYSTEM:PARAMS.DAT: 
NUM_HOST, NUM —SERVER, and WSTYPE. 

- New DISKSIZE parameter replaces the SMALLDISK parameter in 
SYS$SYSTEM:PARAMS.DAT. 

- Additional documentation on modifying AUTOGEN calculations. 

- New section describing the SET HOST/HSC facility. System managers 
can now use most HSC commands and utilities from a remote terminal. 

- New section describing how to use virtual terminals to disconnect from 
a physical terminal without terminating a process. 

• Appendix B—New Cl error log entry descriptions and changes to Cl error 

log entry formats. 





Introduction 


A computer installation exists to provide its users with efficient and 
economical service. The challenge of system management is to provide 
such service on a day-to-day basis. 

Management of a VAX/VMS installation entails two main responsibilities: 
system performance and system operation. These responsibilities require that 
you 

• Make decisions that relate to optimizing the overall performance and 
efficiency of the system 

• Perform tasks that relate to the overall management and control of the 
system 

This manual discusses the issues and facts that you must understand to make 
decisions, and it provides guidelines for performing system management 
functions. 

It is nor possible to prescribe a set of formulas for setting up and running a 
VAX/VMS system, because you cannot manage a system by rote. Rather, 
you must- -by combining an understanding of users' needs with a working 
knowledge of system capabilities—work out your own strategy. 

System management tasks can be performed by a single individual, or by a 
system manager assisted by one or more operators. Since responsibilities vary 
from site to site, this manual does not make job distinctions between system 
managers and operators. As you read the manual, therefore, it may appear at 
times that one person is performing all system management functions. Bear 
in mind that this is not always the case. 


1 System Management Tasks 

System management tasks typically fall into the following categories: 

• Installing and upgrading the system 

• Making site-specific modifications 

• Controlling system operation 

• Configuring the system for good performance 

• Planning to meet future requirements 

The first task is the subject of the Guide to VAX/VMS Software Installation and 
the installation booklets for your VAX processor. The next three are described 
in this manual. The final task is beyond the scope of this manual. 

As system manager, you can perform many of your duties from user 
terminals. However, you must perform one of your chief functions, 
communicating with other users, at an operator's terminal, which you define 
by using the privileged DCL command REPLY/ENABLE (see the VAX/VMS 
DCL Dictionary). 
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Your relationship with users is largely based on messages that pass between 
you and them. A record of these messages is displayed on the operator's 
terminal; the messages are also entered in the operator's log file for later 
reference. 

You can perform certain system management functions only from the system 
console terminal. These functions include bootstrapping the system and 
communicating with the VAX processor's console subsystem. 


1.1.1 Operational Tasks 

The VAX/VMS system normally runs with minimal operator intervention. In 
many installations, however, operators keep the system running smoothly by 
performing some of the following tasks: 

• Physically mounting magnetic tapes and disks at the request of the users 
who own them 

• Initializing and mounting system volumes 

• Backing up public files and volumes 

• Sending messages to users 

• Tending line printers and card readers 

• Responding to emergencies 

• Printing copies of the operator's log file and the error log file 

• Shutting down and restarting the system 

• Bringing up and shutting down network components 

To carry out these tasks effectively, operators usually consult the system 
manager for guidance on site-specific policies and procedures. 


1.1.2 Tools and Privileges 

To manage a VAX/VMS system, you have at your disposal powerful 
commands and utilities to monitor and control system operations and 
resources. In addition, you receive the privileges necessary to carry out 
your management functions. 


1.1.2.1 DIGITAL Command Language Commands 

This manual contains numerous references to the DIGITAL Command 
Language (DCL) commands used most often to keep a VAX/VMS system 
running smoothly. Most of these commands require the OPER user privilege. 
For detailed descriptions of these commands, see the VAX/VMS DCL 
Dictionary. 
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1.1.2.2 VAX/VMS Utilities 

Table 1-1 lists those utilities frequently employed primarily as system 
management tools and gives a brief description of their purpose. You can find 
further details on each of these utilities, as well as other utilities with which 
you will want to become familiar, by referring to the specific VAX/VMS 
utility reference manuals. 


Table 1-1 System Management Utilities 


Utility Name 

Function 

ACCOUNTING 

Produces reports and summaries of system usage 

ANALYZE/ERROR_LOG 

Reports the contents of the system error log file 

AUTHORIZE 

Adds and modifies records in the existing user 
authorization and network authorization files or 
creates new files; adds and modifies records in the 
rights database 

BAD 

Analyzes block-addressable devices and records the 
location of blocks that cannot reliably store data 

DISKQUOTA 

Controls the usage of disk volumes 

INSTALL 

Installs and maintains known images 

MONITOR 

Monitors systemwide performance 

SYSGEN 

Performs tasks associated with system generation 
such as loading and connecting drivers, creating 
or extending page and swap files, displaying or 
modifying the values of the system parameters, and 
enabling multiport memory units 

VERIFY 

Checks the validity of Files-11 Structure Level 1 and 
Structure Level 2 disk volumes, and reports errors 
and inconsistencies 


1.1.2.3 Privileges 

System management functions require privileges that are denied to most 
users. Section 6 provides more detailed information about the privileges and 
who should receive them. Section 5 describes how to set up authorization 
records that grant these privileges. 


1.1.3 VAX/VMS Operating System Components 

To manage a VAX/VMS system effectively, you must be familiar with 
its principal components, which are contained in ten directories on the 
system distribution medium. The logical names of these directories and brief 
descriptions of their contents are as follows: 

• SYS$ERRORLOG—Contains the error log file (ERRLOG.SYS) 

• SYS$EXAMPLES—Contains sample driver programs, user-written system 
services, and other source programs 

• SYS$HELP—Contains text files and help libraries for the Help Utility 

• SYS$LIBRARY or SYS$SHARE—Contains various macro and object 
libraries and shareable images 

• SYS$MAINTENANCE—Contains system diagnostic programs 
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• SYS$MANAGER—Contains files used in managing the operating system 

• SYS$MESSAGE—Contains system message files 

• SYS$SYSTEM—Contains the executable images of most operating system 
functions 

• SYS$TEST—Contains files used in testing operating system functions 

• SYS$UPDATE—Contains files used in applying system updates 

For a complete list of the files contained on the distribution medium, see the 
Guide to VAX/VMS Software Installation. 
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PART I Setting Up the System 




















2 Customizing the Operating System After 
Installation 


Your first responsibility as system manager is to get your VAX/VMS 
system up and running. At a minimum, you must install and bootstrap 
the VAX/VMS operating system supplied by DIGITAL, following procedures 
described in the installation documentation for your VAX processor. Refer to 
this documentation for information on all installation tasks. 

Once your system is installed, you can customize it for your particular 
operating environment by performing one or more of the following 
operations: 

• Build a site-specific startup command procedure 

When you install your system, the site-specific startup command 
procedure, SYS$MANAGER:SYSTARTUP.COM, is blank to accommodate 
the installation. After you have installed the system, you add commands 
to SYSTARTUP.COM to set up an environment specific to your site. For 
example, you normally include commands that initialize and start batch 
and output queues. Section 2.2 describes startup command procedures; 
Section 2.3 shows how to create a typical site-specific startup command 
procedure. 

• Select a default bootstrap command procedure 

The file DEFBOO.CMD is the bootstrap command procedure invoked 
by default to bootstrap your system from the appropriate disk drive, as 
explained in Section 2.4. After installation, you must select and copy 
to DEFBOO.CMD a default bootstrap command procedure from those 
available on your console medium. You can select either a nonstop or a 
conversational procedure. You select a nonstop procedure if you want to 
bootstrap the system without stopping to change system parameters. A 
conversational procedure lets you change parameters in the course of the 
boot. Sections 2.4 and 2.5 explain how to select and, if necessary, modify 
the procedure appropriate for your site. Appendix A discusses bootstrap 
operations peculiar to VAX-11/750 systems. 

• Make site-specific modifications for special configuration or workload 
needs 

When you bootstrap your system during installation, the AUTOGEN 
command procedure generates system parameters that are suitable for 
your hardware. However, you may want to modify some of them if you 
have an unusual hardware configuration or special workload requirements. 
In that case, refer to the discussion of AUTOGEN in Section 11. 

If you have a dual-RL02 VAX-11/730 system, you will need to adjust 
the sizes of the page and swap files to accommodate crash dumps. 
Additionally, if your VAX-11/730 system uses a DMF32 "combo" board, 
you must redefine the line printer device names. These modifications are 
described in Sections 2.6.1 and 2.6.2. 
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Once you have made the necessary site-specific modifications to the 
operating system, you must shut the system down and reboot it to 
ensure that they are installed. For example, most modifications to system 
parameters do not take effect until the system is shut down and rebooted. 
The procedures for shutting down and rebooting the system are explained 
in Sections 2.7 and 4. 

• Back up the system 

After installing and customizing your system, you must perform various 
backup operations as described in Section 2.8. 

The remainder of this chapter discusses the tasks that you as system manager 
perform to customize your newly installed VAX/VMS system and prepare it 
for daily use. 

Section 3 describes procedures for tailoring small-disk systems. 


2.1 Logging In to the System 

Before you can make site-specific modifications, you must log in to the system 
manager's account, SYSTEM. When you bootstrap the system, it announces 
itself with the initialization message: 

VAX/VMS Version 4.4 <dd-mmm-yyyy hh:mm:ss.s> 

mnmm OPCOM, <dd-mmm-yyyy hh:mm:ss.s> im.Um.Vt. 

Logfile has been initialized by operator _0PA0: 

Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1 

%SET-I-INTSET, login interactive limit = 64, Current interactive value = 0 
SYSTEM job terminated at <dd-mmm-yyyy hh:mm:ss.s> 

Use the following procedure to log in to the system as system manager: 

1 Press the RETURN key on the console terminal. 

2 In response to the system's request for your username, type SYSTEM. 

3 In response to the system's request for your password, type the SYSTEM 
password. 

Note: DIGITAL recommends that you change the system manager account 

password frequently to maintain system security. Also, the account has 
full privileges by default, so you must exercise caution when using it. 
Section 6 provides additional information about the SYSTEM account. 

When you enter your password, the system prints a welcome message on the 
console terminal, followed by the time of your last login: 

Welcome to VAX/VMS Version 4.4 

Last interactive login at 15-APR-1986 15:13:21.07 

When the console terminal prints the command prompt, you can begin 
modifying the system using the instructions in the following sections. 
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2.2 Startup Command Procedures 

The software distribution kit includes the following startup command 
procedures: 

• SYS$SYSTEM:STARTUP.COM —a file containing commands that must 
execute at initialization time in order for the system to run properly. This 
procedure is the site-independent startup command procedure supplied by 
DIGITAL. 

• SYS$MANAGER:SYCONFIG.COM —an empty file supplied by 
DIGITAL to which you can add your own specific device configuration 
commands. This command procedure is invoked by STARTUP.COM (see 
Sections 2.2.2 and 2.3). 

• SYS$MANAGER:SYSTARTUP.COM —an empty file supplied by 
DIGITAL to which you can add specific initialization commands for 
your site. This procedure is the site-specific startup command procedure 
invoked by STARTUP.COM (see Section 2.2.3). 

Caution: Do not modify SYS$SYSTEM:STARTUP.COM. Instead, put site-specific 
commands in SYSTARTUP.COM, because new versions of VAX/VMS 
delete and replace the STARTUP.COM command file. By modifying 
SYSTARTUP.COM, you ensure that commands specific to your site are 
kept whenever you upgrade your system to a new version of VAX/VMS. 
Also, leaving STARTUP.COM intact prevents you from inadvertently 
altering any commands in the file. 

Figure 2-1 illustrates the execution sequence of the startup command 
procedures. 

Figure 2-1 Execution Sequence of Startup Command 
Procedures 


SYS$SYSTEM:ST ARTUP.COM SYS$MANAGER:SYCONFIG.COM 



ZK-1309-83 
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2.2.1 Site-Independent Startup Command Procedure 

The command procedure SYS$SYSTEM:STARTUP.COM is automatically 
executed immediately after the operating system is bootstrapped and includes 
commands that 

• Perform various housekeeping chores 

• Define systemwide logical names required for the symbolic debugger, 
language processors, linker, image activator, and help processor 

• Start three processes that control error logging, the job controller, and the 
operator's log 

• Connect devices that are physically attached to the system and load their 
I/O drivers (see Section 2.2.2) 

• Install known images to reduce I/O overhead in activating the most 
commonly run images. 

Before STARTUP.COM terminates, it invokes the site-specific startup 
command procedure, SYS$MANAGER:SYSTARTUP.COM (see Section 2.2.3). 
When SYSTARTUP.COM completes, control is returned to STARTUP.COM 
and the number of interactive users is set to 64 by default, unless the number 
was set in the SYSTARTUP procedure (see Section 2.3.12). After this step, 
STARTUP.COM logs off. 


2.2.2 Device Configuration Command Procedure 

One step in the site-independent startup command procedure 
SYS$SYSTEM:STARTUP.COM is to connect the devices that are 
physically attached to the system and load their I/O drivers. To 
do this, STARTUP.COM first invokes the command procedure 
SYS$MANAGER:SYCONFIG.COM. (Remember that this command procedure 
comes with the software distribution kit as an empty file.) You can leave the 
file empty, or you can add your own specific device configuration commands. 

After SYCONFIG.COM executes control is returned to STARTUP.COM, and 
the following commands are executed to connect all devices automatically 
and load their drivers: 

$ RUN SYS$SYSTEM:SYSGEN 
$ SYSGEN := $SYSGEN 
$ SYSGEN AUTOCONFIGURE ALL 

During autoconfiguration, a section of STARTUP.COM called CONFIGURE 
runs a program that creates a detached process to detect any devices 
connected to an HSC, load their drivers, and make the devices known to 
the system. You can suppress autoconfiguration by including the following 
command as the last line in SYCONFIG.COM: 

$ STARTUP!AUTOCONFIGURE.ALL == 0 

Note: If you set STARTUP$AUTOCONFIGURE _ALL to zero in 

SYSCONFIG.COM, the CONFIGURE section of STARTUP.COM will 
not execute. 
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To ensure proper configuration of devices connected to an HSC, DIGITAL 
recommends adding the following lines to the end of SYCONFIG.COM: 

$ STARTUP$AUTOCONFIGURE_ALL == 0 
$ ®SYS$SYSTEM:STARTUP CONFIGURE 
$ EXIT 

This procedure suppresses autoconfiguration and then executes the commands 
in STARTUP.COM that start the CONFIGURE process. 


2.2.3 Site-Specific Startup Command Procedure 

The command procedure SYS$MANAGER:SYSTARTUP.COM is invoked by 
STARTUP.COM to execute startup commands that are specific to your site. 
DIGITAL recommends that you edit SYSTARTUP.COM to include commands 
that will perform the following typical site-specific operations: 

• Mount public disks 

• Assign systemwide logical names 

• Set the characteristics of terminals and other devices 

• Initialize and start queues 

• Install known images 

• Run the System Dump Analyzer 

• Purge the operator's log file 

• Submit batch jobs that are run at the time the system is initialized and 
that are periodically resubmitted 

• Connect devices and multiport memory units 

• Install or start layered products 

• Install secondary page and swap files 

• Announce that the system is up and running 

• Redefine the number of interactive users 

• Terminate the command procedure 

To minimize processing overhead when executing SYSTARTUP.COM, you 
normally include the DCL command SET NOON at the beginning of the file 
to disable error processing. 


2.3 Creating Your Site-Specific Startup Command Procedure 

The following sections describe how to create a typical site-specific startup 
command procedure. Any commands shown are provided as models; do not 
copy them line for line. 
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2.3.1 Mounting Public Disks 

You will probably want to include mount commands to mount your 
public disks for systemwide access. You should also consider some of the 
advantages of using logical volume names to conceal the physical devices. 
When you mount a disk, MOUNT produces a special logical name called a 
logical volume name that you can use to reference the volume. When you 
dismount the volume, the logical name is deleted. For example: 

$ MOUNT/SYSTEM DRA1: USERFILES USER 

This command produces the logical volume name USER and equates it to the 
concealed device name string DRA1:. However, USER only translates to a 
physical device while the data disk is actually mounted. 

If you mount a disk and do not give an explicit logical volume name, MOUNT 
assigns a default name of the form: DISKS volume-label. In the example 
above, if no logical volume name were specified, the default logical volume 
name would have been DISK$USERFILES. Since the logical volume name is 
printed on the flag page of listings, and displayed on the terminal by the DCL 
commands SHOW DEVICE/FILES and SHOW MEMORY/FILES, you may 
occasionally see such labels. 

If you and the users consistently use the logical volume name, it is not 
necessary to know on which physical drive the volume is mounted. Thus, 
you can avoid including physical device names in programs and command 
procedures. 

Note that when you run SYSTARTUP.COM (and only then), the default on 
the MOUNT command is /NOASSIST. This qualifier means that operator- 
assisted mounts are disabled. If you want to enable this feature during 
SYSTARTUP, you must specify /ASSIST with each MOUNT command. See 
Section 7 for more information on mounting public disks. 


2.3.2 Assigning Systemwide Logical Names 

In addition to the logical names assigned in the site-independent startup 
command procedure, you can assign systemwide logical names with a 
command like the following: 

$ DEFINE/SYSTEM SYSDSK SYS$SYSDEVICE: 

Note: During VAX/VMS system operations where the integrity of the system 

could be compromised by incorrect logical names, such as the activation of 
privileged images (LOGINOUT, MAIL, and so forth), only executive-mode 
and kernel-mode logical names are used; supervisor-mode and user¬ 
mode names are ignored. DIGITAL therefore recommends that logical 
names for important system components (public disks and directories, for 
example,) be defined in executive mode, using the DCL command DEFINE 
/SYSTEM/EXECUTIVE. 

See the VAX/VMS DCL Concepts Manual for more detailed information on 
logical name assignments. 
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2.3.3 Setting Device Characteristics 

To establish the characteristics of the terminals and other devices on the 
system, you can use a series of SET commands in a command procedure. 

You may want to include comments that give the user names for terminal 
owners. For example: 

$ SET TERMINAL TTC2: /SPEED=300/DEVICE_TYPE=LA36/PERMANENT 
$ SET TERMINAL TTD1: /SPEED=9600/PERMANENT 
$ SET TERMINAL TTD4: /SPEED=1200/PERMANENT 
$ SET TERMINAL TTG4: /SPEED=1200/MODEM/PERMANENT 
$ SET PRINTER LPAO: /LOWER/NOCR 
$ SET DEVICE LPAO: /SPOOLED 

Note that the /SPEED qualifier sets both transmission and reception speeds 
to the same value. The /MODEM qualifier defines a terminal for use on a 
dial-in line. Printer characteristics (SET PRINTER and SET DEVICE above) 
must be set prior to establishing queues for the printers. You may want to 
include SET TERMINAL commands in a separate file named, for example, 
TERMSET.COM, and include a command in SYSTARTUP.COM to invoke the 
TERMSET.COM command file. When the command file finishes execution, 
control returns to SYSTARTUP.COM. 


!JONES 
!WRENS 
!JRSMITH 
SDIALUP1 


2.3.4 Initializing and Starting Queues 

Include queue commands to start the system job queue manager, establish 
spooled devices, and set up print and batch queues. 

Initialize and start each queue with a separate INITIALIZE/QUEUE/START 
command line. The following commands start the system job queue manager 
and initialize and start all queues if they are stopped. 

$ ! 

$ !Start the system job queue manager 

$ ! 

$ START/QUEUE/MANAGER 

$ ! 

$ !Set printers spooled and establish printer queues 

$ ! 

$ SET PRINTER/LOWER LPAO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/NOENABLE_GENERIC LPAO: 

$ ! 

$ SET PRINTER/LOWER LPBO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPBO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/NOENABLE_GENERIC LPBO: 

$ ! 

$ INITIALIZE/QUEUE/START/GENERIC=(LPAO,LPBO) SYS$PRINT 

$ ! 

$ !Establish batch queues 

$ ! 

$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=2/BASE_PRI0RITY=3 SYS$BATCH 

Note: You may want to add the /RESTART qualifier to the START/QUEUE 
/MANAGER command. This qualifier causes the queue manager 
to automatically restart in the event of a job controller abort (see 
Section 9.3.3 for more information). 

On systems with a large number of queues, you may want to include queue 
commands in a separate file named, for example, STARTQ.COM, and 
include a command in SYSTARTUP.COM to invoke the queue command 
file. When the queue command file finishes execution, control returns to 
SYSTARTUP.COM. (Section 9 describes how to set up queues and establish 
spooled devices.) 
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2.3.5 Installing Known Images 

It is important to install user and system programs (in addition to the ones 
installed in the site-independent startup command procedure) so that they 
can be located quickly, shared, or provided privileges: 

$ INSTALL = "IINSTALL/COMMAND.MODE" 

$ INSTALL 

ADD/OPEN/SHARED/HEADER.RESIDENT BLISS32 
ADD/OPEN/SHARED MACR032 
ADD/OPEN DIRECTORY 

For more information on installing images as known images, see Section 8 
and the description of the Install Utility in the VAX/VMS Install Utility 
Reference Manual. 


2.3.6 Running the System Dump Analyzer 

Each time the system is bootstrapped, you should run the System Dump 
Analyzer (SDA) in case the system failed the last time it was running: 

$ ANALYZE/CRASH.DUMP SYS$SYSTEM:SYSDUMP.DMP 

COPY SYS$ERRORLOG:SYSDUMP.DMP 

SET OUTPUT LPAO:SYSDUMP.LIS 

SHOW CRASH 

SHOW STACK/ALL 

SHOW SUMMARY 

SHOW PROCESS/PCB/PHD/REGISTERS 
EXIT 

If you require further information, you can invoke the System Dump Analyzer 
for an interactive session upon completion of startup. (See the VAX/VMS 
System Dump Analyzer Reference Manual.) 

Caution: If you use the page file for the crash dump file, you must, when the 

system reboots, issue the SDA command COPY to copy the dump from 
the page file to another file suitable for analysis. If you fail to perform 
the copy operation, pages used to save the crash dump information will 
not be released for paging, and your system will hang while executing 
STARTUP.COM in the rebooting process. 


2.3.7 Maintaining the Operator's Log File 

Section 10 offers some suggestions for maintaining the operator's log file. If 
you decide not to put them into practice, you might instead add the following 
command to purge all but the last two versions of the operator's log file: 

$ PURGE/KEEP=2 SYS$MANAGER:OPERATOR.LOG 


2.3.8 Submitting Standard Batch Jobs 

Some sites may have batch jobs that are submitted at system startup time and 
that resubmit themselves to run at intervals as long as the system is running. 
For such jobs, the DCL command SUBMIT is used in the startup file: 

$ SUBMIT SYS$MANAGER:file-spec 

(See Section 9.5.5 for more information on submitting batch jobs.) 
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2.3.9 Connecting Devices and Multiport Memory Units 

You run the System Generation Utility (SYSGEN) to connect devices not 
automatically connected in STARTUP.COM and to initialize or connect 
multiport memory units: 

$ RUN SYS$SYSTEM:SYSGEN 

SHARE MPM1 SHR_MEM_1 /INITIALIZE 

For installations that require permanent residence of the console block storage 
device, you must explicitly connect the device by issuing the following 
SYSGEN command: 

CONNECT CONSOLE 

See Section 11 and the VAX/VMS System Generation Utility Reference Manual 
for a detailed discussion of SYSGEN. 

You should also mount the console block storage device by using a command 
like the following: 

$ MOUNT/FOREIGN/SYSTEM/PROTECTION*(SYSTEM:RWLP) CSA1: CONSOLE 

Failure to mount the console block storage device with appropriate protection 
permits users to mount and access it, because the device is in RT-11 format 
and has no file protection. 


2.3.10 Installing Secondary Page and Swap Files 

You run SYSGEN to install secondary page and swap files (previously created 
with the SYSGEN command CREATE). 

$ RUN SYS$SYSTEM:SYSGEN 

INSTALL DISK$SYS2:[SYSTEM]PAGEFILE1.SYS /PAGEFILE 
INSTALL DISK$SYS2:[SYSTEM]SWAPFILE1.SYS /SWAPFILE 


2.3.11 Providing Announcements 

The last command in SYSTARTUP.COM typically announces to all terminals 
that the system is up and running: 

$ REPLY/ALL/BELL "VAX/VMS at ACME. INC. ready lor use." 

Before SYSTARTUP.COM exits, you may want to provide site-specific 
definitions for one or both of the following logical names: SYS$ANNOUNCE 
and SYS$WELCOME. These logical names are checked whenever a user logs 
in and provide special messages at that time. 


2.3.11.1 SYS$ANNOUNCE 

SYS$ANNOUNCE defines text to be printed whenever a user begins to log 
in; that is, the text is printed immediately after a successful dial-in, CTRL/Y, 
or RETURN is received. The text may consist of up to 63 characters. For 
longer messages, you can precede the name of a text-containing file with an 
at sign (@) so that the login command procedure prints the entire file as an 
announcement. 

For example, you could include a command of the following form in your 
SYSTARTUP.COM file: 

$ DEFINE/SYSTEM SYS$ANNOUNCE "ENTER IF YOU DARE" 
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Or you might prefer to print a file: 

$ DEFINE/SYSTEM SYS$ANNOUNCE "®SYS$MANAGER:ANNOUNCE.TXT" 

If you do not define SYS$ANNOUNCE, no announcement is printed. 


2.3.11.2 SYSSWELCOME 

SYS$WELCOME defines text to be printed whenever a user succeeds in 
logging in; that is, the text is printed immediately after the correct password 
is entered. The text may consist of up to 63 characters. For longer messages, 
you can precede the name of a text-containing file with an at sign (@) 
so that the login command procedure prints the entire file as a welcoming 
announcement. 

For example, you could include a command of the following form in your 
SYSTARTUP.COM file: 

$ DEFINE/SYSTEM SYS$WELCOME "WELCOME TO VAX/VMS LAND" 

Or you might prefer to print a file: 

$ DEFINE/SYSTEM SYSlWELCOME "®SYS$MANAGER:WELCOME.TXT" 

If you do not specifically define SYSSWELCOME, the standard VAX/VMS 
welcome message is printed: 

Welcome to VAX/VMS Version 4.4 

Note that this message may end by specifying the DECnet-VAX node name if 
the logical name SYSSNODE is defined. 


2.3.12 Redefining the Number of Interactive Users 

If the number of interactive users that you permit to log in at one time is not 
64, include the following command in SYSTARTUP.COM: 

$ STARTUP$INTERACTIVE_LOGINS == n 

Specify the appropriate number of users for n. 

When SYSTARTUP.COM terminates, control is returned to STARTUP.COM, 
which checks whether the number of logins was set by the above command. 
If the command was used to specify a value, that value is used. Otherwise, 
STARTUP.COM sets the number to 64 by default and then exits. 


2.3.13 TerminatingSYSTARTUP.COM 

Include the command EXIT as the last command in SYSTARTUP.COM. 
The EXIT command terminates the procedure and returns control to 
STARTUP.COM. 
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2.4 Selecting a Default Bootstrap Command Procedure 

Default bootstrap command procedures are grouped by types of disk 
controller systems: Integrated Disk Controllers (IDC), UNIBUS Disk Adapters 
(UDA), UNIBUS controllers. Hierarchical Storage Controllers (HSC), and 
MASSBUS controllers. In all cases, the bootstrap command procedures are 
stored on your console media: floppy diskettes for VAX-11/780, TU58 tape 
cassettes for VAX-11/750 and VAX-11/730, console RL02 disk for VAX 8600. 

After your system is installed, you must select a default bootstrap command 
procedure from those available on your console volume. To determine which 
procedures are available, follow these steps: 

1 Be sure your console device is connected. If it is not, invoke SYSGEN and 
issue the following command to connect it: 

SYSGEN> CONNECT CONSOLE 

2 Next, exit from SYSGEN and mount the console volume as foreign (it is 
in RT-11 format). In this example, the console volume is assumed to be 
physically located in the floppy diskette drive (CSA1) on a VAX-11/780. 

$ MOUNT/FOREIGN CSA1: 

3 Now invoke the Exchange Utility using the following DCL command: 

$ EXCHANGE 

4 When the EXCHANGE > prompt appears, enter the following command 
to obtain a listing of the files on the console volume: 

EXCHANGE> DIRECTORY CSA1: 

When the listing is printed, examine it to determine which bootstrap 
command procedures are available for bootstrapping system devices. 
Generally, these are the files that start with the letter D and end with 
either BOO.CMD (nonstop) or GEN. (conversational). 

You may also find files that begin with the letters Cl. These are used to 
bootstrap from HSC disks (see Section 4.2.4). 

You can relate each procedure to a disk device by noting the first two 
letters in the file name, which represent the device code. For example, 
files beginning with the letters DM are used for bootstrapping RK07 disk 
devices. (See the discussion of SYSGEN in the VAX/VMS System Generation 
Utility Reference Manual for a list of device codes for the various disk drives.) 

The third character in the file name is usually a number identical to the unit 
number of the associated disk device. For example, DMlBOO.CMD is used 
for bootstrapping the RK07 assigned unit number 1 on the first UNIBUS 
controller. 

If the third character is a letter (A, B, C, or D), you may use the file to 
bootstrap devices assigned to the related controller (A is the first controller, 

B the second, and so on). For example, you use DMBBOO.CMD (third 
character is B) to bootstrap from RK07 disk drives assigned to the second 
UNIBUS controller. When you use this type of procedure, you must provide 
the device unit number either by editing the procedure to deposit the selected 
number in register R3 (the unit number register), or by using the console 
DEPOSIT command to put the selected number in R3. 
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For example, if you want to bootstrap from the RK07 drive assigned unit 
number 3 on the third UNIBUS controller, you would add this line to the 
bootstrap file named DMCBOO.CMD: 

DEPOSIT R3 00000003 IDISK DEVICE UNIT NUMBER 


2.5 Modifying a Default Bootstrap Command Procedure 

Once you have selected a default bootstrap command procedure for your site, 
you may find it necessary to modify the procedure if 

• You want to bootstrap your system from a disk drive other than your 
usual system device. 

• You use CIBOO.CMD or a bootstrap command file that does not specify 
the disk drive's unit number (see Section 4.2.4). 

You cannot modify a file on your console volume because of the way the 
volume is formatted. You must first copy the file to a disk directory, then 
modify it, and finally copy it back to the console volume. To perform the 
copy operations, use the DXCOPY command procedure as follows: 

1 Invoke DXCOPY: 

$ <OSYS$UPDATE: DXCOPY 

2 When the command procedure asks whether the console storage medium 
is mounted, type the letter Y: 

Is the system console storage medium mounted (Y/N)?: Y 

3 When DXCOPY asks if you want to copy a file from the console storage 
medium (to your default directory), type Y: 

Copy from console medium (Y/N)?: Y 

4 When DXCOPY prompts you for it, type the name of the file you want to 
copy to your default directory: 

Name of file to be copied?: file-spec 

$ 

DXCOPY copies the file and returns you to command level. 

When the DCL prompt appears, you can edit and rename the default 
bootstrap command procedure file while it resides in your default 
directory. If you want to make the modified file your default bootstrap 
command procedure, rename the file to DEFBOO.CMD using the 
following command: 

$ RENAME filename DEFBOO.CMD 

5 Invoke DXCOPY to copy the modified procedure back to the console 
storage medium: 

$ (BSYSIUPDATE: DXCOPY 

6 When the command procedure asks whether the console storage medium 
is mounted, type the letter Y: 

Is the system console storage medium mounted (Y/N)?: Y 

7 When DXCOPY asks whether you want to copy from the console medium, 
type N: 

Copy from console medium (Y/N)?: N 
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The negative response tells DXCOPY you want to copy the file from your 
default directory to the console storage medium. 

8 When the command procedure asks for it, type the name of the file to be 
copied from your default directory to the console storage medium. In this 
example, you type DEFBOO.CMD: 

Name of file to be copied?: DEFBOO.CMD 

$ 

DXCOPY responds by copying the modified file to the console volume 
and returning you to command level. 

You may now use the file to bootstrap your system disk from the selected 
device. 


2.6 Performing Modifications for Special Configurations or 
Workload Requirements 

When you first bootstrap your system, the DIGITAL-supplied command 
procedure SYS$UPDATE:AUTOGEN.COM sets the values of the system 
parameters, the sizes of the page, swap, and dump files, and the contents of 
the default installed image list. 

AUTOGEN provides the appropriate values based on your hardware 
configuration and on estimates that AUTOGEN makes for typical workloads. 
However, you may need to modify the system parameters if you have an 
unusual hardware configuration or special workload requirements. Procedures 
for making such modifications are described in the discussion of AUTOGEN 
in Section 11. 


2.6.1 Modifying Dual-RL02 Systems to Handle Crash Dumps 

The dual-RL02 system does not provide a dump file for handling crash 
dumps. Instead, the page file is used for this purpose. However, a dual-RL02 
configuration can utilize the page file for crash dumps only if the page file has 
at least 1000 more blocks than the number of physical pages of memory on 
the system, and the swap file has at least 1000 blocks. 

You may need to enlarge the size of these files in a dual-RL02 system because 
AUTOGEN creates page and swap files of minimal size in order to conserve 
space. To change the size of these files, refer to the AUTOGEN discussion in 
Section 11. 


2.6.2 Redefining the Line Printer on a VAX—11 /730 

Line printer device names on VAX-11/730 processors that use a DMF32 
"combo" board are defined as LC. All other line printer names are defined 
as LP. To avoid problems with programs and procedures that use the LP 
designation, it is recommended that the line printer device name be redefined 
by adding the following commands to your site-specific SYSTARTUP.COM 
command procedure: 

$ DEFINE /SYSTEM LP LCAO: 

$ DEFINE /SYSTEM LPO LCAO: 

$ DEFINE /SYSTEM LPA LCAO: 

$ DEFINE /SYSTEM LPA0 LCAO: 
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2.7 Rebooting to Install System Modifications 

You must shut your system down and then reboot it to ensure that all the 
modifications you make are installed in the system. For example, note that 
any system parameters that were added by running the AUTOGEN command 
procedure do not take effect until you reboot the system. 

You can shut down and reboot the system with AUTOGEN commands, 
or you can execute SHUTDOWN.COM using the following procedure. 
(Section 4 describes SHUTDOWN.COM in more detail.) If your system 
controls are set for automatic restart, and your default bootstrap command 
procedure is set to bootstrap your system disk, you need only perform the 
first step. 

Caution: For VAX-11/750 systems, be sure the BOOT DEVICE switch on the 

Processor Control Panel is positioned to select the disk drive that contains 
the system disk. 

1 Type the following command at the DCL prompt: 

$ ®SYS$SYSTEM:SHUTDOWN 

This shutdown command procedure asks you several questions, such as 
the number of minutes until system shutdown and the reason for the 
shutdown. The questions pertain to situations where you are doing an 
orderly shutdown with users logged in to the system. You may either 
provide specific answers to these questions, or simply press the RETURN 
key to enter default values. 

When you see the following message, the system is ready to shut down: 

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM 

2 Use CTRL/P to halt the system. When the console prompt prints out 
(> > > ), the system is shut down. 

3 Reboot the system by typing BOOT on the console terminal, or by 
activating the BOOT switch on the Processor Control Panel. 

Note: For the VAX-11/750, put the POWER ON ACTION switch in the 
RESTART/BOOT position. 

The system responds with a message in the following format: 

VAX/VMS Version 4.4 <dd-mmm-yyyy hh:mm:ss.s> 

XXXXXXXXXXX OPCOM. <dd-mmm-yyyy hh:rm:s8.8> XXXXXXXXXXX 

Loglile has been initialized by operator _OPAO: 

Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1 

y.SET-1-INTSET, login interactive limit = 64, Current interactive value = 0 
SYSTEM job terminated at <dd-mmm-yyyy hh:mm:ss.s> 
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2.8 Backing Up the System 

Once you have installed and customized your system, DIGITAL recommends 
that you perform the following operations (in order): 

• Back up the console volume 

• Back up the system disk 

• Build and copy a system disk 

Step-by-step procedures are presented in the following sections. 


2.8.1 Backing Up the Console Volume 

You should make a backup copy of your console volume to protect 
against corruption of your original. Sections 2.8.1.1 and 2.8.1.2 describe, 
respectively, the procedures for backing up the console volume on VAX 
system configurations with a single console storage device (VAX-11/780, 
VAX-11/750) and for systems with two console storage devices (VAX-11/730 
and VAX-11/725). 

The operating system provides a command procedure called 
CONSCOPY.COM in SYS$UPDATE that is designed to help you copy 
your console volume to a blank one. You may use this procedure with 
any member of the VAX family. Section 2.8.1.1 describes the use of 
CONSCOPY.COM on VAX-11/780 and VAX-11/750 processors. If you 
have a dual-drive console subsystem (currently available only on 
VAX-11/730 and VAX-11/725 systems), refer to Section 2.8.1.2. 


2.8.1.1 Console Volume Backups for Single-Drive Console Subsystems 

The procedure described here applies directly to backing up the console 
volume (floppy diskette media) on a VAX-11/780. However, by making 
appropriate substitutions, you can also use it to back up the console volume 
on other processors; for example, substitute "VAX-11/750" for "VAX-11/780" 
and "console TU58" for "console floppy diskette". 

This is a two-step procedure. First you save the console floppy diskette files 
on a scratch disk directory; then you restore the files in the scratch directory to 
an initialized floppy diskette. (You can use the blank floppy diskette included 
in your distribution kit.) 

To use CONSCOPY, proceed as follows: 

1 Log in to the system manager's account. 

2 At the DCL prompt, enter the following command: 

$ <BSYS$UPDATE: CONSCOPY 

CONSCOPY execution begins with this announcement: 

SYSIUPDATE : CONSCOPY . COM 
Save or restore a VMS console medium. 

3 Enter your processor type at the following CONSCOPY prompt: 

Which kit do you want to build [780, 750, 730, or 8600, default 780]: 
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When you enter your response, CONSCOPY processes it, and then 
explains its operations: 

A SAVE operation involves copying the console medium to 
an RT-11 virtual volume, which is a Files-11 file that 
is an image of the RT-11 console volume. 

A RESTORE operation involves copying the entire contents 
of a virtual volume to a console medium. 

4 When CONSCOPY asks which operation you want, enter SAVE: 

Do you want to SAVE or RESTORE your console floppy?: SAVE 

5 Next, CONSCOPY prompts for the name of the virtual disk (see 
explanation above) to which files are to be saved. Press the RETURN 
key to select the default (SYS$DISK:CONSOLE.DSK): 

Enter file name of virtual disk [default SYS$DISK:CONSOLE:DSK]: I RET 1 

6 To verify the copy operation, press the RETURN key in response to the 
following prompt: 

Do you want log messages as files are copied? [Y/N, default YES] 1 RET 1 

7 CONSCOPY processes your response, and then prompts for the name of 
the console device. Enter CSA1. 

Enter console device drive (DDCU:): CSA1: 

8 At the following prompt, insert your console volume in the console drive 
and press RETURN: 

Put your console floppy into d rive _CSA1:, 
and type <RETURN> when ready: 1 RET| 

Note: You probably already have your console volume in the drive; this 

request is more appropriate to the restore operation, during which you 
must mount a target console volume in the drive. 

When you indicate you are ready to continue, CONSCOPY mounts the 
console volume, and then invokes the Exchange Utility to begin the save 
operation. Several EXCHANGE messages are displayed, followed by file 
header information and a list of the files that are being saved. 

After completing the save operation, CONSCOPY prompts you to put your 
console floppy diskette back into the console drive and press RETURN 
when you are ready. (Again, this action is more appropriate to the restore 
operation.) CONSCOPY then mounts the console volume with SYSTEM 
and NOWRITE protection and returns you to command level. 

The second phase of the console backup is the restoration of the console 
image from the virtual disk files to RT-11 format on an initialized medium. 

1 At the DCL prompt, again invoke CONSCOPY: 

$ <DSYS$UPDATE: CONSCOPY 

2 CONSCOPY announces itself and asks: 

Which kit do you want to build [780, 760, 730 or 8600, default 780] : 

Enter the same response as for the save operation. 

3 After CONSCOPY describes its two operations and asks which one you 
want, enter RESTORE. 

4 WHEN CONSCOPY prompts for the name of the virtual disk , enter the 
same response as for the save operation. 


2-16 




Customizing the Operating System After Installation 


5 Next, tell CONSCOPY whether you want to log messages as files are 
copied. 

6 When CONSCOPY prompts for the name of the console device, again 
enter CSA1. 

7 At the following prompt, insert the target floppy diskette in the console 
drive, and then press RETURN: 

Put your console floppy into d rive _CSA1:, 
and type <RETURN> when ready: I RET 1 

CONSCOPY mounts the target floppy diskette, and invokes the Exchange 
Utility to execute the restore operation. Several EXCHANGE messages are 
displayed, followed by file header information and a list of the files that 
are being saved. 

When the restore operation is completed, CONSCOPY prompts you to put 
your original console floppy diskette back into the console drive and to 
indicate when you are ready to continue by pressing RETURN. 

After you press RETURN, CONSCOPY mounts the console volume with 
SYSTEM and NO WRITE protection and returns you to command level. 


2.8.1.2 Console Volume Backups for Dual-Drive Console Subsystems 

This section provides a procedure for backing up your console volume if you 
have a dual-drive console subsystem. The procedure is simplified because 
of the dual-drive capability. First, you insert your original console TU58 in 
CSA2, and a scratch TU58 in CSA1. Then, after mounting both devices, you 
use the DCL command BACKUP to back up the original console TU58 onto 
the scratch TU58. 

You may use the blank TU58 included in your distribution kit if it was not 
used for another purpose. 

1 Log in to the system manager's account. 

2 Check that the console TU58 is in CSA2. 

3 Place a blank cartridge in CSA1. Be sure that the WRITE PROTECT tab 
on the TU58 cartridge is set to permit writing, that is, slid in the direction 
of the arrow inscribed on it. 

4 Invoke SYSGEN from command level: 

$ RUN SYS$SYSTEM:SYSGEN 

When the SYSGEN > prompt appears, enter the following command: 

SYSGEN> CONNECT CONSOLE 

5 Then exit from SYSGEN: 

SYSGEN> EXIT 

6 When SYSGEN terminates, it returns you to command level. Mount CSA1 
with this command: 

$ MOUNT/FOREIGN CSA1 

7 When the system confirms the mount, mount CSA2: 

$ MOUNT/FOREIGN/NOWRITE CSA2 

8 When the system confirms the mount, back up the console TU58 to a 
blank TU58: 

$ BACKUP/PHYSICAL/VERIFY CSA2: CSA1: 


2-17 








Customizing the Operating System After Installation 


9 It takes approximately 30 minutes for BACKUP to complete the operation. 
When the command level prompt appears, dismount the two cartridges 
with the following commands: 

$ DISMOUNT CSA1 
$ DISMOUNT CSA2 

You should use the newly created console cartridge as your console TU58 to 
verify its correctness. Treat the original as the backup copy. 


2.8.2 Backing Up the System Disk 

To back up your system disk, DIGITAL recommends that you use standalone 
BACKUP, which employs a subset of Backup Utility qualifiers. (Refer to 
the VAX/VMS Backup Utility Reference Manual for a complete description 
of the Backup Utility and its qualifiers.) It is especially important that you 
understand the functions of the /IMAGE and /PHYSICAL qualifiers before 
using standalone BACKUP. 

/IMAGE Allows you to create a functionally equivalent copy of the entire 

volume or volume set. 

/PHYSICAL Copies, saves, restores, or compares the entire volume in terms 
of logical blocks, ignoring any file structure. 

If your system is distributed on magnetic tape, standalone BACKUP is 
provided on the console media. (DIGITAL recommends making a copy of 
standalone BACKUP on the console media.) 

If your system was not distributed on magnetic tape, you must build a 
standalone BACKUP kit either on console media or on disk. You can then 
bootstrap standalone BACKUP from the console block storage device or from 
the alternate directory root SYSE on a Files-11 disk. 

Installing and using standalone BACKUP in an alternate root on your system 
disk saves time when you are backing up your system disk, because you do 
not have to boot standalone BACKUP from your console volume—a relatively 
slow process. 

The procedures described here apply to all VAX processors. However, you 
should note the following: 

• You can install standalone BACKUP in any available disk directory root 
from SYS1 through SYSE; however, DIGITAL has established SYSE as 
the standard alternate system directory root for standalone BACKUP. The 
discussion in this section assumes you will install standalone BACKUP in 
SYSE. 

• You cannot use these procedures to restore your operating system to the 
system disk from which standalone BACKUP is booted. 

• There are some limitations with regard to the VAX-11/750, which are 
noted within the procedures. 

• The console device is CSA1 on VAX systems with a single console drive 
and CSA2 on systems with two console drives. 

The following sections explain how to 

• Install standalone BACKUP in alternate directory root SYSE 
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• Create a command procedure to bootstrap standalone BACKUP from 
SYSE. 

• Bootstrap standalone BACKUP from SYSE 

• Build a standalone BACKUP kit on console media 

• Bootstrap standalone BACKUP from console media 


2.8.2.1 Installing Standalone BACKUP in Alternate System Root SYSE 

You install standalone BACKUP in SYSE using the STABACKIT command 
procedure. First, log in to the SYSTEM account. Then, enter this command: 

$ ®SYS$UPDATE:STABACKIT SYS$SYSDEVICE: 

Be sure to enter the command exactly as shown. 

After you install standalone BACKUP in SYSE, the next step is to create a 
command procedure to boot it. 


2.8.2.2 Creating a Command Procedure to Bootstrap Standalone BACKUP 

The recommended procedure for creating a command procedure to boot 
standalone BACKUP from alternate root SYSE is to modify an existing boot 
command procedure. Ideally, this should be the default boot command 
procedure, DEFBOO.CMD (DEFBOO.COM for VAX 8600 series processors). 

First, make a copy of the boot procedure in your default device directory. 
Then, edit the copy as instructed. Finally, give the edited copy an appropriate 
file name, and store it on the console volume. 

You may choose any unique name in the form xxxBOO.CMD (or 
xxxBOO.COM for VAX 8600) for the command procedure you create. 
However, DIGITAL suggests you use a file name identical to the copied 
file, except that the first letter should be an X. 

For example, if you use a copy of DEFBOO.CMD, the new file should be 
named XEFBOO.CMD. 

The following procedure assumes you will use a copy of DEFBOO.CMD and 
rename it XEFBOO.CMD. 

1 If necessary, use the following command sequence to configure the console 
device: 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT CONSOLE 
SYSGEN> EXIT 

2 Insert the console volume into the console device. 

3 Invoke the Exchange Utility to make a copy of DEFBOO.CMD in your 
default disk directory: 

For VAX-11/780 and VAX-11/750: 

$ EXCHANGE COPY CS1:DEFBOO.CMD * 

For VAX-11/730 and VAX-11/725: 

$ EXCHANGE COPY CS2:DEFBOO.CMD * 

4 Rename the copy of DEFBOO.CMD in your default directory. 

$ RENAME DEFBOO.CMD XEFBOO.CMD 
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5 Invoke an editor to modify XEFBOO.CMD. The table below shows how to 
determine the line that you must modify for your processor; it shows the 
line before and after you change it. Note that you change only the first 
digit. 


Processor Type 

Line to Change 

Line After Change 

VAX 8650 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 

EXXXXXXX 

VAX 8600 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 

EXXXXXXX 

VAX-11/785 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 

EXXXXXXX 

VAX-11/782 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 

EXXXXXXX 

VAX-11/780 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 

EXXXXXXX 

VAX-11/750 

D/G 5 XXXXXXXX 

D/G 5 EXXXXXXX 

VAX-11/730 

D/G/L 5 XXXXXXXX 

D/G/L 5 EXXXXXXX 

VAX-11/725 

D/G/L 5 XXXXXXXX 

D/G/L 5 EXXXXXXX 


6 When you have edited the file, call EXCHANGE to store it on the console 
volume: 

For VAX-11/780 and VAX-11/750: 

$ EXCHANGE COPY XEFBOO.CMD CSA1: 

For VAX-11/730 and VAX-11/725: 

$ EXCHANGE COPY XEFBOO.CMD CSA2: 


2.8.2.3 Bootstrapping Standalone BACKUP from SYSE 

To boot standalone BACKUP from SYSE, you must perform the following 
operations: 

1 Shut the system down. 

$ CSYSISYSTEM:SHUTDOWN.COM 

2 The procedure asks the following questions. Respond by pressing the 
RETURN key. 

How many minutes until final shutd own? [0] I RET 1 
Reason for shutdown? [Standalone] I RET| 

Do you want to spin down the disk volumes? [NO] I RETI 

3 As the shutdown continues, the console terminal prints several shutdown 
messages. When the console terminal prints the following message, 
shutdown is completed: 

SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM 

At this point, halt the processor using CTRL/P. 

4 When the processor halts, enter the following command to boot 
standalone BACKUP from SYSE: 

For VAX-11/750: 

»> B/E0000000 
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For all other processors: 

»> B XEF 

5 If you are not using a modified version of the default bootstrap command 
procedure to boot standalone BACKUP, use the first three characters in the 
name of the bootstrap command procedure you created. For example, if 
you are using XUOBOO.CMD, type the following command: 

»> B XUO 

6 When the application volume is booted, standalone BACKUP identifies 
itself and displays the dollar sign ($) prompt: 

7.BACKUP -1 - IDENT, Standalone BACKUP V4.4; the date is <dd-nunm-yyyy hh:mm> 

$ 


2.8.2.4 Building a Standalone BACKUP Kit on Console Media 

To build a standalone BACKUP kit on console media (RX01 diskettes, TU58 
cartridges, an RL02 disk, and so forth), use the STABACKIT command 
procedure. For the purpose of illustration, the procedure described in this 
section assumes RX01 diskettes as the console media. 

Note that the procedure may differ slightly for processors that use TU58 
cartridges or other console media. For example, if your processor is a VAX 
8600, standalone BACKUP is stored on a single RL02 disk, and you are 
not prompted to insert additional volumes. If you have a VAX-11/780, the 
console media are RX01 diskettes. For most other VAX systems, the console 
media are TU58 cartridges. For VAX 8200 processor, the console medium is 
an RX50 diskette. (See the specific processor installation guide for detailed 
installation procedures.) 

To build a standalone BACKUP kit on RX01 diskettes, proceed as follows: 

1 Label four blank RX01 floppy diskettes SYSTEM_1, SYSTEM_2, 
SYSTEM_3, and BACKUP, respectively. 

Note: The number of standalone BACKUP console volumes may vary for 
different processors. 

2 Log in as system manager and invoke STABACKIT.COM. 

3 When STABACKIT prompts you for the name of the target device, enter 
CSA1:. 

4 After you have identified the target device, STABACKIT tells you that four 
blank floppies are needed to build the kit: three for the standalone VMS 
files, and the fourth for the BACKUP application image. 

STABACKIT also allows you either to build the VMS files as a system 
kit without building the application kit (in this case BACKUP), or to 
build both the system and application kits. Respond to both questions by 
pressing the RETURN key. 

5 Next, STABACKIT gives you the option of using the Bad Block Locator 
Utility (BAD) to check for bad blocks on the target diskette. BAD requires 
approximately 15 additional minutes for each diskette, but it may save 
time by finding bad blocks that would otherwise cause problems in 
building the kit. 

Note: If you are building the kit on TU58 cartridges, allow approximately 
two hours to run BAD (40 minutes per tape). 
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6 When STABACKIT prompts, insert the first system floppy diskette (labeled 
SYSTEM _1) in the console drive and enter YES when you are ready to 
continue: 

Please place the first system floppy diskette in drive _CSA1:. 

This volume will receive the volume label SYSTEM_1. 

Enter "YES" when ready: YES 

If you elect to run BAD, STABACKIT displays the following message: 

Analyzing floppy diskette for bad blocks . . . 

SYSTEM.1 mounted on _CSA1: 

The test takes approximately 15 minutes (40 minutes for each TU58). 
Upon completion, BAD reports the number of blocks on the diskette and 
the number that are bad. Then STABACKIT mounts the floppy diskette, 
creates the directory [SYSO.SYSEXE], and copies to it the set of system files 
while displaying appropriate messages. 

7 When the last file is copied, STABACKIT prompts you to insert the next 
floppy diskette. Replace the floppy diskette labeled SYSTEM_1 with the 
floppy diskette labeled SYSTEM_2; then enter YES when you are ready 
to continue: 

Please place the second system floppy diskette in drive _CSA1:. 

This volume will receive the volume label SYSTEM.2. 

Enter "YES" when ready: YES 

STABACKIT runs BAD (assuming you selected this option), mounts the 
floppy diskette, and copies to [SYSO.SYSEXE] the set of system files while 
displaying the appropriate messages. 

8 When the last file is copied, STABACKIT prompts you to insert the next 
floppy diskette. Replace the floppy diskette labeled SYSTEM_2 with the 
floppy diskette labeled SYSTEM_3; then enter YES when you are ready 
to continue: 

Please place the second system floppy diskette in drive _CSAi:. 

This volume will receive the volume label SYSTEM.3. 

Enter "YES" when ready: YES 

STABACKIT runs BAD (assuming you selected this option), mounts the 
floppy diskette, and copies to [SYSO.SYSEXE] the set of system files while 
displaying the appropriate messages. 

9 When the last file is copied, STABACKIT prompts you to insert the fourth 
RX01 diskette. Replace the floppy diskette labeled SYSTEM—3 with the 
application floppy diskette labeled BACKUP, and enter YES when you are 
ready to continue: 

Please place the application floppy diskette in drive _CSA1:. 

This volume will receive the volume label BACKUP. 

Enter "YES" when ready: YES 

STABACKIT runs BAD, mounts the floppy diskette, and copies the 
executable BACKUP image (STABACKUP.EXE) to [SYSO.SYSEXE]. 

10 When the next message appears (indicating that the kit is built), replace 
the floppy diskette labeled BACKUP with the console floppy diskette; then 
enter YES when you are ready to continue: 

The console volume will be mounted /NOWRITE for protection. 

Please replace the original console floppy diskette. 

Enter "YES" when ready: YES 
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The procedure responds by mounting the console floppy diskette, 
reporting the starting and ending times, and then returning you to 
command level. 


2.8.2.5 Bootstrapping Standalone BACKUP from Console Media 

For purposes of illustration, the procedure described in this section assumes 
TU58 cartridges as the console media. However, the procedure is also 
applicable to other types of console media. 

Note: The number of standalone BACKUP console volumes may vary for 
different processors. 

To bootstrap standalone BACKUP from console media, follow these steps: 

1 On VAX-11/780, VAX-11/750, and VAX 8600 systems insert the console 
media and go to Step 3. For most other processors, insert the console 
TU58 in the CSA2 drive, and insert the standalone volume labeled 
SYSTEM_1 in the CSA1 drive. (On UDA- or RA80-based VAX-11/730 
systems and VAX-11/725 systems, CSA1 is on the right-hand side of the 
processor control panel. On UDA-based VAX-11/730 systems, CSA1 is 
the left-hand drive.) 

2 If the processor is not in console mode, press CTRL/P. 

3 When the console terminal prints the console mode prompt (> > > ), 
issue the following command: 

For VAX 8600, VAX 8200, VAX-11/780, VAX-11/730, VAX-11/725: 

»> B CS1 

For VAX-11/750: 

»> B DDAO 

4 You will be prompted to place successively in the console drive the 
volumes containing the standalone BACKUP kit. Note that if your 
processor is a VAX 8600, standalone BACKUP is stored on a single RL02 
disk, and you will not be prompted to insert additional volumes. The 
first prompt directs you to replace the console TU58 with the standalone 
volume labeled SYSTEM _1 and to enter YES when you are ready to 
continue. (On VAX-11/730 and VAX-11/725 systems, you are prompted 
to replace the SYSTEM_1 volume in the console device with the first 
standalone volume; ignore the message and just enter YES.) When you 
enter YES (or Y), the procedure displays this message: 

Resuming load operation on volume 'SYSTEM_1', please stand by... 

(Proceed on VAX-11/750 systems as described for VAX-11/730 and 
VAX-11/725 systems.) 

5 When the first volume is booted, the procedure prompts you to replace it 
with the standalone volume labeled SYSTEM_2 and to enter YES when 
you are ready to continue. When you enter YES, the procedure displays 
the following message: 

Resuming load operation on volume 'SYSTEM_2', please stand by... 

6 This procedure is repeated for the volume labeled SYSTEM _3. When 
the third volume finishes booting, the standalone system announces itself 
and may ask you to enter the date and time, depending on whether your 
processor has a time-of-year clock. If a calendar year has ended since 
the software was generated, you will be prompted for date and time. 
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Enter the information in the format displayed by the prompt and press 
RETURN. 

Note: If applicable, the standalone system configures and lists your HSC and 
MSCP-served devices. If you are building your system on an HSC 
disk, enter the appropriate device name from this list in place of the 
variable system device when you restore the required save set. For 
detailed information on restoring the save set, refer to the installation 
booklet for your VAX processor. 

7 Next, the procedure prompts you to replace the third volume with the 
application volume labeled BACKUP and to enter YES when you are 
ready to continue. 

When you enter YES, the procedure displays this message: 

Resuming load operation on volume 'BACKUP', please stand by... 

When the application volume is booted, standalone BACKUP identifies 
itself and displays the dollar sign ($) prompt: 

y,B ACKUP -1 - IDENT, Standalone BACKUP V4.4; the date is <dd-mmm-yyyy hh:mm> 

$ 

Issue the appropriate BACKUP command; for example, this command 
format is adequate for most BACKUP operations: 

BACKUP/IMAGE/VERIFY/LIST=llcu: ddcu: mmcu:savset.bck/SAVE 

where 

lieu: 

A line printer (for example LPAO) to print a listing of BACKUP save sets. 

ddcu: 

A system disk (for example DRAO). 

mmcu: 

A save set destination device (for example MTAO). 

See the VAX/VMS Backup Utility Reference Manual for more information 
on BACKUP commands and qualifiers. 

Note: Do not remove the BACKUP cartridge from the CSA1 drive until 
directed to do so. 

When your backups are completed, press CTRL/P to halt the processor and 
terminate standalone BACKUP. 


2.8.3 Building and Copying a VAX/VMS System Disk 

At some point, you may want to transport your operating system files to 
another disk. For example, assume that your operating system is initially 
stored on an RK07 disk together with some of your user files. Assume further 
that you have purchased an RP06 disk drive and that you want to move 
only the operating system files from the RK07 to the RP06. You can build 
the operating system on the RP06 without affecting the user files on the 
RK07 by using the VMSKITBLD command procedure. You should note that 
the VMSKITBLD BUILD function effectively eliminates any software on the 
target disk. 
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Another way to use VMSKITBLD.COM is illustrated in this situation. Assume 
that you are currently using an RK07 to store operating system files and 
user files, and that you have an RP06 that you are using for user files. You 
decide to purchase additional optional software products that layer onto the 
operating system, but you do not have enough space on the RK07 for the 
additional software. Here, you would like to move the operating system files 
to the RP06 without affecting the user files on the RP06. In this situation, 
you can use the COPY capability of VMSKITBLD because the COPY function 
does not affect files that are currently on the target disk. 


2.8.3.1 Building the Operating System on Another Disk 

If you want to build your operating system on another disk, and you are not 
concerned about losing anything on the target disk, use the VMSKITBLD 
BUILD function as illustrated in the following procedure. 

Note: VMSKITBLD.COM, automatically dismounts the target disk when the kit 
is completed. 

1 Bootstrap the operating system from the source disk, typically an RK07. 

2 Log in to the system manager's account. 

3 Establish SYS$UPDATE as the default directory: 

$ SET DEFAULT SYSlUPDATE 

4 Place the target disk (assuming you are using a removable disk) in an 
appropriate drive and put it on line. 

5 Enter the following command to invoke VMSKITBLD.COM: 

$ ©VMSKITBLD 

6 In response to VMSKITBLD prompts, supply the requested information 
about the source and target disk drives. 

7 After you supply the required information, VMSKITBLD asks: 

Operation [BUILD.ADD.COPY.COMMON]? 

Enter the word BUILD. (If you want your target disk to be built as a 
cluster-common system disk, also enter COMMON.) 

Caution: The BUILD option destroys all previous information on the target disk 
before it builds the operating system. 

When the build resumes, you will receive messages that either prompt 
you for information needed to complete the operation, or inform you of 
the procedure's status. 

A typical message sequence might look like this: 

Enter mounted source disk name (DDCU:): SYS$SYSDEVICE: 

Enter SOURCE disk top level system dir ector y [default = SYSO]: I RET 1 

Enter target disk name (DDCU:): DRAO: I RET 1 

Enter the target disk's label [default = VAXVMSRL4]: | 

Enter TARGET disk top level system directory [default = SYSO]: l RE T J 
It will be necessary to initialize the target disk. 

Is the target disk, DRAO:, ready to be initialized? (Y/N): Y 
_DRAO: allocated 
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'/.MOUNT-I-MOUNTED, VAXVMSRL4 mounted on _DRAO: 

Create directory entries on the target disk. 

Copy the system executive files. 

Copy the system library files. 

Copy the system message files. 

Copy the system manager files. 

Copy the system update command files. 

Copy the system EXE files. 

Copy the system help files. 

Write a bootblock. 

Copy BLISS require files and STARLET DCL library. 

Copy coding examples. 

Copy the UETP files. 

When the system disk is built, VMSKITBLD.COM automatically dismounts 
the disk, and then sends the following message to your terminal: 

Kit is complete. 

8 At this point, the target disk contains all the required VAX/VMS files for a 
complete system. You can configure the system properly by bootstrapping 
with the default parameters and then using the AUTOGEN procedure to 
configure the target system. 

If you have a VAX-11/780, bootstrap the system with the default 
parameters, using the GEN version of the bootstrap command file: 

»> ©dduGEN 

If you have a VAX-11/750, enter: 

»> B/l ddcu 

9 When the SYSBOOT> prompt appears, enter the following commands: 

SYSB00T> USE DEFAULT 
SYSB00T> CONTINUE 

10 After the system bootstraps, log in as system manager and run the 
AUTOGEN procedure described in Section 11. 


2.8.3.2 Copying the Operating System Files to Another Disk 

You can also use VMSKITBLD.COM to copy the operating system files to a 
target disk without affecting the files that are already on it. But first, your 
VAX/VMS system must be running and the source disk that you intend to 
copy must be mounted. 

Note: VMSKITBLD.COM automatically dismounts the target disk when the kit 
is completed. 

Often, this source disk is the system disk from which the system was 
bootstrapped. Proceed as follows to copy the source disk to a target disk: 

1 Log in to the system manager's account. 

2 Establish SYS$UPDATE as the default directory: 

$ SET DEFAULT SYS$UPDATE 

3 Place the target disk on an appropriate drive. 

4 Enter the following command to invoke VMSKITBLD: 

$ ©VMSKITBLD 

5 In response to VMSKITBLD prompts, supply the requested information 
about the source and target disk drives. 
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6 After you supply this information, VMSKITBLD asks: 

Operation [BUILD,ADD,COPY.COMMON]? 

Enter the word COPY. 

7 After you reply, you will receive messages that either prompt you for 
information needed to complete the copy operation, or inform you of the 
procedure's status. 

8 When the copy operation is finished, VMSKITBLD automatically 
dismounts the disk and sends you the following message: 

Kit is complete. 


2.8.3.3 Adding an Operating System to an Existing System Disk 

There are cirumstances in which you will find it convenient to add another 
operating system to a system disk: 

• You want to test software on a new operating system version. You could, 
for example, install the new version on an alternate directory root and 
create a bootstrap command procedure to select that version for testing 
sessions. 

• You need to conserve disk drives. 

Note that you must add the new system on an unused directory root. Use 
the ADD function of VMSKITBLD.COM in SYS$UPDATE, as illustrated 
in the following prodedure. (Do not confuse this function with the 
MAKEROOT.COM command procedure, which creates system directory 
roots for VAXcluster member nodes.) 

1 Log in to the system manager's account. 

2 Establish SYS$UPDATE as the default directory: 

$ SET DEFAULT SYS$UPDATE 

3 Place the target system disk (assuming you are using a removable disk) in 
an appropriate drive and put it on line. 

4 Enter the following command to invoke VMSKITBLD.COM: 

$ <D VMSKITBLD 

5 In response to VMSKITBLD prompts, supply the requested information. 

6 After you supply the information, VMSKITBLD asks: 

Operation [BUILD.ADD.COPY.COMMON]? 

Enter the word ADD. 

You will receive messages that either prompt you for information needed 
to complete the operation, or inform you of the procedure's status. 

When you are prompted for the mounted source disk name, enter 
SYS$SYSROOT: if the source is a common root; otherwise, enter 
SYS$SYSDEVICE:. 

When you are prompted for the source disk top level system directory, 
enter the directory from which you wish to copy system files. 

When you are prompted for the target disk top level system directory, be 
sure to enter a directory root not already in use. (Note that in addition 
to roots used by existing systems on the disk, roots SYSE and SYSF are 
reserved for other system functions.) 
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A typical message sequence might look like this: 

Enter mounted source disk name (DDCU:): SYS$SYSROOT: 

Enter SOURCE disk top level system directory [def ault = SYSO]: SYS4 I RET| 

Enter target disk name (DDCU:): SHEMPlDUAl: I RET| 

Enter the target disk's label [default = VAXVMSRL4]: IRET| 

Enter TARGET disk top level system directory [default = SYSO]: SYSA I RET| 
Allocate and mount target disk. 

_SHEMP$DUA1: allocated 

‘/.MOUNT-1-MOUNTED, VAXVMSRL4 mounted on _SHEMP$DUA1: 

Create directory entries on the target disk. 

Copy the system executive files. 

Copy the system library files. 

Copy the system message files. 

Copy the system manager files. 

Copy the system update command files. 

Copy the system EXE files. 

Copy the system help files. 

Write a bootblock. 

Copy BLISS require files and STARLET DCL library. 

Copy coding examples. 

Copy the UETP files. 

VMSKITBLD.COM informs you when the operation completes by sending 
the following message to your terminal: 

Kit is complete. 

At this point, the target system directory contains all the required 
VAX/VMS files for a complete system. (Note that if any layered products 
from the source system are needed on the new system, you must reinstall 
them.) 

7 Create a bootstrap command procedure, as follows, to boot the new 
operating system. (Note that for VAX-11/730 and VAX-11/725, the 
console device is CSA2:.) 

a Copy DEFBOO.CMD (DEFBOO.COM for VAX 8600) from the console 
medium to your default disk directory, renaming the file SYxBOO.CMD 
(or SYxBOO.COM), where x represents the selected root. For example, 
if you wish to boot from SYSA, name the file SYABOO.CMD: 

$ RUN SYSISYSTEM:SYSGEN 
CONNECT CONSOLE 
$ MOUNT /FOREIGN CSA1: 

$ EXCHANGE COPY /LOG CSA1:DEFBOO.CMD SYABOO.CMD 

b Invoke an editor to modify SYABOO.CMD. The table below shows 
how to determine the line that you must change for your processor; it 
shows the line before and after you change it. Note that you change 
only the first digit. 


Processor 

Line to Change 

Line After Change 

VAX 8650 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 AXXXXXXX 

VAX 8600 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 AXXXXXXX 

VAX-1 1/785 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 AXXXXXXX 

VAX-1 1/782 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 AXXXXXXX 

VAX-11/780 

DEPOSIT R5 XXXXXXXX 

DEPOSIT R5 AXXXXXXX 

VAX-11/750 

D/G 5 XXXXXXXX 

D/G 5 AXXXXXXX 

VAX-11/730 

D/G/L 5 XXXXXXXX 

D/G/L 5 AXXXXXXX 

VAX-11/725 

D/G/L 5 XXXXXXXX 

D/G/L 5 AXXXXXXX 
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c Copy the edited file back to the console medium: 

$ EXCHANGE COPY /LOG SYABOO.CMD CSA1: 

8 After shutting down the system and pressing CTRL/P to halt the 
processor, you can bootstrap with the procedure you created. 

• For processors other than the VAX-11/750, enter the following 
command at the console prompt: 

»> B SYA 

• On the VAX-11/750, you can boot in two ways: 
a From unit 0 (DB0:,DM0:,DR0:,DU0:): 

»> B/AXXXXXXX 

b From the console TU58: 

»> B DDAO 
B00T58> B SYA 

When the SYSBOOT> prompt appears, enter the following commands: 

SYSB00T> USE DEFAULT 
SYSB00T> CONTINUE 

If you are running in a VAXcluster, it is important to verify and, if 
necessary, reset values (using SHOW and SET commands) for the 
following SYSGEN parameters before rebooting: 

• ALLOCLASS 

• DISK-QUORUM 

• QUORUM 

• SCSSYSTEMID 

• SCSSYSTEMIDH 

• SCSNODE 

• VAXCLUSTER 

• VOTES 

For more information on these parameters, refer to the VAX/VMS System 
Generation Utility Reference Manual or the Guide to VAXclusters. 

9 After the system bootstraps, log in as system manager and run the 
AUTOGEN procedure described in Section 11. 
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Customizing Small-Disk Systems 


This chapter discusses the VAX/VMS small-disk environment, including 
supported configurations, operating system file groups, the VAX/VMS 
Tailoring facility (VMSTAILOR), and operating procedures peculiar to small- 
disk systems. Error and informational messages from the facility are also 
described. 

Currently, DIGITAL supports the following small-disk systems: 

• VAX-11/725 systems 

• Systems with dual-RK07 disk configurations 

During an installation or upgrade procedure, you indicate that you want 
to generate a tailored system by responding to the appropriate prompts. 

You can then use the Tailoring facility to customize your system for specific 
applications. 

Note: Tailoring is presently supported only on system configurations that have 
less than 140,000 blocks of disk space. 

In small-disk systems, a library disk supplements the system disk. At any 
instant, the system disk need include only those portions of the operating 
system that are necessary to perform a particular task. Whenever you want to 
tailor your system disk for a certain task, you use tailoring commands to copy 
the appropriate operating system files from the library disk to the system disk 
and to remove from the system disk any files that are not needed. In this 
way, you obtain additional space for user files on the system disk. (Tailoring 
commands are described in Section 7.3.) 

Note that the size of the library disk must be at least 20,000 blocks. 
Moreover, if it is less than 30,000 blocks, there will be insufficient space 
for the optional save set, which includes the system map, BLISS require files, 
and the SYS$EXAMPLES directory. 


3.1 DIGITAL-Supplied File Groups 

To facilitate tailoring procedures in small-disk environments, operating 
system files are divided into groups. A file group is a file that lists each file in 
a particular group in the following format: 

[directory]name.type 

DIGITAL supplies a standard set of file groups with small-disk systems. For 
added flexibility, you can create your own file groups, using the format of the 
DIGITAL-supplied file groups. This section describes the file groups provided 
by DIGITAL; the next section outlines procedures for creating site-specific file 
groups. 

Files provided by DIGITAL on the library disk are divided into task-related 
groups. For example, the files used to manage queues are collected in a 
file group called QUEUES. When you want queue management capability, 
you specify QUEUES as the parameter for the tailoring COPY command. 
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VMSTAILOR then copies all files in the QUEUES file group from the library 
disk to the system disk. 

Conversely, if you do not need a particular operating system function, you 
can remove the related file group from the system disk. For example, after 
you run the User Environment Test Package (UETP), you can remove the 
operating system files that support this function by specifying UETP as the 
parameter in a tailoring DELETE command. 

Following is a list with a brief description of the DIGITAL-supplied file 
groups. The approximate size of each group, in blocks, is included in the list 
to help you make tailoring decisions. 

SYSTEM FILE GROUP 

• REQUIRED—files needed to boot the VAX/VMS operating system and 
to perform basic file manipulations, such as COPY, RENAME, and 
TAILORING, and to provide all the features of the VMS executive. 
Support for all standard VAX processors and devices is included. These 
files should not be removed from the system disk. (6423 blocks) 

LIBRARY FILE GROUPS 

• BLISSREQ—source files used to generate compile-time libraries during 
VAX BLISS language installation. These files may be deleted after the 
BLISS language installation is complete. (2816 blocks) 

• DECNET—files that give the system a local networking capability. 
However, you must purchase a separate kit and license to gain multinode 
networking capability. (1309 blocks) 

• DEVELOP—files used for the development of application programs. 

They include the EDT editor, MACRO assembler, VAX/VMS Librarian, 
VAX/VMS Linker, VAX/VMS Debugger, and the libraries that they use. 
Help text for these utilities is also included. (8098 blocks) 

• EXAMPLES—programming examples for various VAX/VMS applications, 
along with the system map. These examples are also reproduced in the 
microfiche source listings. (1643 blocks) 

• FILETOOLS—utilities used to analyze and dump files and to create and 
modify ISAM files. (610 blocks) 

• HELP—help text displayed by the VMS HELP command and various 
system utilities. (4363 blocks) 

• LIBRARY—libraries used during the assembly, linking, and compilation of 
programs. (5753 blocks) 

• MANAGER—files used to perform system management functions. They 
include accounting, disk quota, volume preparation and maintenance, and 
user authorization functions, as well as command procedures used by the 
system manager. (1575 blocks) 

• MISCTOOLS—system programming support tools, tools for analyzing 
crash dumps, and other miscellaneous tools. (2306 blocks) 

• QUEUES—files that are used to initialize, start, and stop the batch and 
device queues, and to submit jobs. (194 blocks) 

• TEXTTOOLS—files used for text editing and text formatting. They include 
all editors and DIGITAL Standard Runoff. (580 blocks) 
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• UETP—User Environment Test Package files, which provide a variety of 
tests to ensure that your VMS system is operating properly. (494 blocks) 

To obtain a list of files in a file group, invoke the Tailoring facility with the 
following DCL command: 

$ <BSYS$UPDATE: VMSTAILOR 

When the system responds with the Tailor > prompt, you can request, for 
example, a list of files in the QUEUES file group: 

Tailor> DIRECTORY QUEUES 

Contents of QUEUES Group 


[SYSEXE]INPSMB.EXE 
[SYSEXE]PRTSMB.EXE 
[SYSEXE]QUEMAN.EXE 
[SYSEXE]SUBMIT.EXE 
[SYSEXE]SMBSRVSHR.EXE 


3.2 Creating Site-Specific File Groups 

You can create file groups for your own site-specific applications by following 
the format of the DIGITAL-supplied file groups. Be sure, however, not 
to modify the file groups provided by DIGITAL, because they are used 
for system updates and upgrades as well as for optional software product 
installations. 

You may use any text editor to create a file that lists a file group. If you create 
a new file group by modifying a copy of a DIGITAL-supplied file group, be 
sure to assign a new file name to the file you create, and be careful not to 
modify the DIGITAL-supplied file. For example, if you want to create your 
own text-processing file group by editing SYS$UPDATE:TEXTTOOLS.TLR 
with the EDT editor, the following command will ensure that the new file has 
a new name and that the DIGITAL-supplied file is not altered: 

$ EDIT /OUTPUT=new_rile_name SYS$UPDATE:TEXTTOOLS.TLR 

Since the DIGITAL-supplied system file group files reside in the 
SYS$UPDATE directory on the system disk and have the file type TLR, 
you need not include the device, directory, or file type when you refer to 
them in tailoring commands. 

If you want to put the file groups you create in a different directory or 
on a different device, you must explicitly specify the files in the tailoring 
commands. For example, if you create a file group named SPECIAL.TLR and 
store it in directory [USER.JOBS] on device USER$DISK, use the following 
command to copy it to the system disk: 

Tailor> COPY USER$DISK:[USER.JOBS]SPECIAL 
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3.3 Tailoring Commands 

The Tailoring facility provides a set of commands and qualifiers you use to 
tailor your system disk. The key to tailoring is knowing which file groups you 
need to support your system operations, and then copying only those groups 
to the system disk. 

There are two ways to issue tailoring commands. You can either invoke the 
facility and enter commands at the tailoring command level, or you can, with 
a single DCL command, specify a particular tailoring function. 

To work from the tailoring command level, use the following procedure: 

1 Log in under the system manager's account. 

2 At the DCL prompt, enter the following command: 

$ ®SYS$UPDATE:VMSTAILOR 

The system responds with the Tailor > prompt to indicate that you are at 
the tailoring command level. 

To return to DCL level, use the tailoring command EXIT. 

If you want to tailor from DCL level, enter a single-line DCL command to 
invoke tailoring and specify the tailoring function you want. For example, if 
you are at DCL level and you want to copy the TEXTTOOLS file group to the 
system disk, first make sure that the library disk has been mounted with the 
tailoring command MOUNT, and then enter the following command: 

$ ®SYS$UPDATE:VMSTAILOR COPY TEXTTOOLS 

DCL invokes the Tailoring facility, which executes the command and returns 
you to DCL level. 

Table 3-1 summarizes the VMSTAILOR commands. When you use tailoring 
commands, observe the following rules: 

• The commands that use file group names as parameters accept any unique 
abbreviation of a name. However, if you have created a file group that 
resides in a device and directory other than SYS$UPDATE, you will have 
to be explicit in identifying the device and directory when you specify the 
file group name as a parameter. 

• For the COPY, DELETE, DIRECTORY/SIZE, and RECORD commands 
to execute, the library disk must be mounted with the tailoring command 
MOUNT. 

• The library disk should be used as a read-only source of VAX/VMS 
file groups. In order to support system upgrades and updates, its 
contents should not be altered. Mount the library disk with the /WRITE 
qualifier only during maintenance updates or layered product installations. 
(VMSINSTAL, for example, mounts the library disk /WRITE.) 

• The /LIBRARY qualifier is reserved for use by the command procedures 
that are used to do updates and upgrades. You should never use this 
qualifier when you are tailoring your system. 

Caution: If you alter your library disk, you will produce an unsupported software 
configuration that may result in incorrect system operation. 
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Table 3-1 VMSTAILOR Command Summary 


Command 

Function 

COPY file-group[, . . . ] 

Copies the specified file groups from the 
library disk to the system disk 

DELETE file-group[, . . . ] 

Deletes previously copied file groups from 
the system disk 

DIRECTORY file-group[, . . . ] 

Gives a directory of the files in the 
specified file groups 

DISMOUNT [ddcu:] 

Dismounts the library disk from the 
specified device 

EXIT 

Exits from the Tailoring facility 

HELP [topic] [subtopic] 

Explains the specified tailoring commands 
and qualifiers 

MOUNT ddcu: [label] 

Mounts the library disk on the specified 
device 

RECORD match [revised] 

Creates a file listing all VAX/VMS files 
found on the library disk that have a match 
on the system disk 

SEARCH file-spec 

Locates the file groups in which the 
specified file resides 


COPY Command 

Copies file groups or individual files in the specified file groups from the 
library disk to the system disk. The copied files replace any older versions. 
The COPY command takes the form: 

COPY file-group[,...] 

/CONFIRM 

/FILE 

/LIBRARY 

/LOG 

file-group 

Specifies one or more file groups or an individual file to be copied. 

/CONFIRM 

Asks you to confirm that you want each file in the group copied. If you 
respond with N, the associated file is not copied. If you reply Y or press the 
RETURN key, the file is copied. 

/FILE 

Indicates that an individual file is to be copied instead of a file group. You 
must use a file specification in place of the file group parameter with this 
qualifier. A default device and directory of LIB$SYSROOT:[SYSEXE] and a 
default file type of EXE are assumed. When you use the /LIBRARY qualifier 
with the /FILE qualifier in update and upgrade command procedures, a 
default device and directory of SYS$SPECIFIC:[SYSEXE] and a default file 
type of EXE are assumed. You may use wildcards in the file specification, but 
not lists of file specifications. 
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/LIBRARY 

This qualifier is reserved for use by update and upgrade command procedures 
to copy files from the system disk to the library disk. Do not specify this 
qualifier when using tailoring commands interactively. 

/LOG 

Displays the name of each file that is copied. 

Example 

The following command copies files in the QUEUES and FILETOOLS groups 
from the library disk to the system disk and displays the name of each file at 
the terminal. 

Tailor> COPY/LOG QUEUES.FILETOOLS 

The facility responds by listing the files that are copied. 

If the system disk does not have enough space to copy a file group, you 
receive the following message: 

'/.BACKUP-E-OPENOUT, error opening SYS$SPECIFIC: [SYSEXE] EDF. EXE; 1 as output 
-RMS-F-FUL, device lull (insufficient space for allocation) 

If this happens, you can use the DELETE command to remove unnecessary 
files from the system disk and then try copying again. 

DELETE Command 

Deletes all versions of each file in the specified file groups from the system 
disk. The command checks for a backup copy on the library disk before doing 
the deletion. The DELETE command takes the form: 

DELETE file-group[....] 

/CONFIRM 

/FILE 

/LIBRARY 

/LOG 

/OVERRIDE 

file-group 

Specifies one or more file groups or an individual file to be deleted from 
the system disk. The REQUIRED file group cannot be deleted using this 
command. 

/CONFIRM 

Asks for confirmation before deleting each file. If you enter N or press the 
RETURN key, the file is not deleted. If you enter Y, the file is deleted. 

/FILE 

Indicates that an individual file is to be deleted instead of a file group. You 
must use a file specification in place of the file group parameter with this 
qualifier. A default device and directory of LIB$SYSROOT:[SYSEXE] and a 
default file type of EXE are assumed. When you use the /LIBRARY qualifier 
with the /FILE qualifier in update and upgrade command procedures, a 
default device and directory of SYS$SPECIFIC:[SYSEXE] and a default file 
type of EXE are assumed. You may use wildcards in the file specification, but 
not lists of file specifications. 
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/LIBRARY 

This qualifier is reserved for use by update and upgrade command procedures 
to delete files from the library disk. Do not specify this qualifier when using 
tailoring commands interactively. 

/LOG 

Displays the name of each file that is deleted. 

/OVERRIDE 

Overrides the check for a backup copy before deleting. This qualifier permits 
you to delete files on the system disk without having to mount the library 
disk. 

Example 

The following command deletes the files in the LIBRARY group from the 
system disk. 

Tailor> DELETE/CONFIRM LIBRARY 

The facility then displays the name of each file that you may elect to delete 
and asks you to confirm the deletion by entering Y: 

SYS$SPECIFIC:[SYSEXE]MP.STB;1 delete? (Y or N) : Y 
SYS$SPECIFIC:[SYSEXE]SYS.STB;1 delete? (Y or N) : Y 
SYSISPECIFIC:[SYSEXE]SYSDEF.STB;1 delete? (Y or N) : Y 
SYS$SPECIFIC:[SYSLIB]FORDEF.FOR;1 delete? (Y or N) : Y 
SYS$SPECIFIC:[SYSLIB]FORIOSDEF.FOR;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]IMAGELIB.OLB;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]LIB.MLB;1 delete? (Y or N) : N 
SYS$SPECIFIC:[SYSLIB]LIBDEF.FOR;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]MTHDEF.FOR;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]SIGDEF.FOR;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]STARLET.MLB;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]STARLET.OLB;1 delete? (Y or N) : N 
SYSISPECIFIC:[SYSLIB]XFDEF.OLB;1 delete? (Y or N) : N 

DIRECTORY Command 

Lists the contents of the specified file groups. The DIRECTORY command 
takes the form: 

DIRECTORY file-group [_] 

/GROUPS 

/OUTPUT=file-spec 
/SIZE 

file-group 

Specifies the file group. 

/GROUPS 

Lists all the file groups available in the SYS$UPDATE directory. No 
parameters are allowed with this qualifier. 

/OUTPUT=file-spec 

Requests that the output listing be written to the specified file rather than to 
the current SYS$OUTPUT device. The default file type is LIS. 

/SIZE 

Requests that the size of each file be displayed along with its name. 
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Example 

The following command lists the files in the HELP and REQUIRED groups in 
an output file called HELREQ.LIS. 

Tailor> DIRECTORY/OUTPUT=HELREQ HELP,REQUIRED 

DISMOUNT Command 

Dismounts the library disk from the specified device and deassigns the logical 
names defined by VMSTAILOR when the disk was mounted. Table 3-2 lists 
these logical names. 


Table 3-2 Library Disk Logical Name Definitions 


Logical Name 

Definition 

LIB$SYSDEVICE 

= ddcu: 

LIBSTOPSYS 

= SYSO 

LIBSSYSROOT 

= ddcu:[SYSO.] 

LIB$ERRORLOG 

= LIBSSYSROOT :[SYSERR] 

LIBSHELP 

= LIBSSYSROOT :[SYSHLP] 

LIBSLIBRARY 

= LIBSSYSROOT :[SYSLIB] 

LIBSMAINTENANCE 

= LIBSSYSROOT :[SYSMAINT] 

LIB$MANAGER 

= LIBSSYSROOT :[SYSMGR] 

LIB$MESSAGE 

= LIBSSYSROOT :[SYSMSG] 

LIB$SHARE 

= LIBSSYSROOT :[SYSLIB] 

LIBSSYSTEM 

= LIBSSYSROOT :[SYSEXE] 

LIB$TEST 

= LIBSSYSROOT :[SYSTEST] 

LIB$UPDATE 

= LIBSSYSROOT :[SYSUPD] 


The DISMOUNT command takes the form: 

DISMOUNT [ddcu:] 

ddcu: 

Specifies the drive from which you want to dismount the library disk. If you 
do not specify a device, the logical name LIB$SYSDEVICE: is used as the 
default. 

EXIT Command 

Exits from the Tailoring facility and returns you to DCL level. The EXIT 
command takes the form: 

EXIT 

HELP Command 

Gives detailed descriptions of all the tailoring commands and qualifiers. If 
you type only HELP, you will receive an explanation of the HELP command 
and a list of other topics described in the Help file. The HELP command 
takes the form: 

HELP [topic] [subtopic] 
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topic 

Specifies any of the commands, plus the additional topic of GROUPS. 

subtopic 

Can be a qualifier when used with a command topic, or a group name when 
used with the GROUP topic. 

Example 

The following command displays information about the DEVELOP file group. 

Tailor> HELP GROUPS DEVELOP 

The system responds with the following information: 

GROUPS 

DEVELOP 

Develop files are used for the development of application 
programs. They include the EDT editor, MACRO-32 assembler, 

VAX/VMS librarian, VAX/VMS linker, VAX/VMS Debugger, and 
the libraries they use. Help text for the mentioned utilities 
is also included. 

MOUNT Command 

Mounts the library disk on the specified disk drive, and defines appropriate 
logical names (see Table 3-2). To use the COPY, DELETE, DIRECTORY 
/SIZE, and RECORD commands, you must have mounted the library disk 
with the MOUNT command. The MOUNT command uses the format: 

MOUNT[/WRITE] ddcu: [label] 

/WRITE 

Lets you write to the library disk. Use the /WRITE qualifier only if you are 
installing optional software or if you want to run the UETP. 

ddcu: 

Specifies the drive on which you wish to mount the library disk. 

label 

Specifies the label of the library disk you wish to mount. VAXVMSLB4 is the 
default label. 

Caution: If you alter your library disk, you will produce an unsupported software 
configuration, and you may adversely affect system operation. The library 
disk is write protected by default. 

Example 

The following command mounts the library disk in the DQA1 drive: 

Tailor> MOUNT DQA1: 

RECORD Command 

Creates a file group containing names of all the VMS files on the library disk 
that currently match those on the system disk. With this command, you can 
save a record of a unique group of files for later use. The RECORD command 
takes the form: 

RECORD match-file-group [revised-file-group] 
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match-file-group 

Provides a name for the match-file group you want to create. Both the name 
and revision date of a file must match on both disks for the file to be listed 
in this file group. If multiple versions of a file exist, only the latest version is 
compared and listed. 

revised-file-group 

Provides a name for the revised-file group you want to create. This group 
includes the files on the system disk that have a matching name on the library 
disk but have a different revision date. If you do not specify a revised-file 
group and there are revised files on the system disk, you receive an error 
message for each revised file. 

A RECORD command is typically followed by a DELETE command to allow 
another software configuration to be created on the system disk. Then the file 
group created by the RECORD command can be copied back to the system 
disk at a later date, restoring the old configuration. 

Examples 

To list the current tailored software configuration in a file group called 
MYCONFIG, invoke VMSTAILOR, mount the library disk using the MOUNT 
command, and issue the following RECORD command: 

Tailor> RECORD MYCONFIG 

Now delete MYCONFIG from the system disk, using the DELETE command. 

Tailor> DELETE MYCONFIG 

You can then build a new system disk configuration by copying other file 
groups to the system disk. For example, if you wish to create an environment 
in which system management functions can be performed, you would issue 
the following command: 

Tailor> COPY MANAGER 

Now you can dismount the library disk with the tailoring DISMOUNT 
command, and perform system management operations. When you want 
to restore the previous configuration, remount the library disk and type the 
following commands: 

Tailor> DELETE MANAGER 
Tailor> COPY MYCONFIG 

SEARCH Command 

Locates the file group(s) in which a specified file resides. The SEARCH 
command takes the form: 

SEARCH file-spec 

file-spec 

Specifies the name of a file to be located. No wildcards are allowed. Output 
is written to SYS$OUTPUT. 
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3.4 Special Operations for Small-Disk Systems 

The space limitations of a small-disk system require you to perform certain 
operations differently than you would in a large-disk environment. These 
operations are 

• Running the UETP 

• Enabling job queues 

• Analyzing system failures 

• Installing image files with privileges 

• Copying to the system disk image files needed for DCL commands 
The following sections describe procedures for performing these operations. 


3.4.1 Preparing to Run the UETP 

The User Environment Test Package (UETP) tests your hardware and software 
to verify that your system has been properly installed. If you are running the 
UETP on a small-disk system, such as a VAX-11/730, you should be aware 
of the disk space limitations. Because of the space limitations, you need to 
perform special procedures to prepare for a UETP run. You can run the UETP 
in either of two ways on a small-disk system: 

• From the library disk (LIB$SYSROOT) 

• From the system disk, after copying the appropriate files 

The methods of preparing a small-disk system for UETP testing are described 
in the following sections. 


3.4.1.1 Running the UETP from the Library Disk 

Running the UETP from the library disk is the easier of the two methods and 
leaves more space on your system disk; however, it allows the UETP to write 
to your library disk. If you plan to run the UETP from LIB$SYSROOT, use 
the following procedure: 

1 Log in under the SYSTEST account. 

2 Place the library disk in drive DQA1. 

3 Invoke the tailoring procedure and mount the library disk as writeable 
with the following command: 

$ (DSYSIUPDATE:VMSTAILOR MOUNT/WRITE DQA1: 

4 Start the UETP with the following command: 

$ <9LIB$TEST: UETP 
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3.4.1.2 Running the UETP from the System Disk 

As an alternative, you can run the UETP from the system disk. This method 
of running the UETP allows you to reserve your library disk as read-only, but 
it is more complicated and uses more space on your system disk. 

If you plan to run the UETP from your system disk, you must first mount the 
library disk with the tailoring command MOUNT, then copy the UETP file 
group to your system disk. If you want to remove the library disk during a 
run of the UETP, you must tailor additional files to the system disk before 
you invoke the UETP. 

1 Log in under the SYSTEST account. 

2 Place the library disk in drive DQA1. 

3 Invoke the tailoring procedure with the following command: 

$ <DSYS$UPDATE: VMSTAILOR 

4 Enter the following sequence of tailoring commands: 

Tailor> MOUNT DQA1: 

Tailor> COPY UETP 

5 If you want to remove the library disk during the UETP run, enter the 
additional tailoring commands: 

Tailor> COPY /FILE CONVERT 

Tailor> COPY /FILE [SYSLIB]CONVSHR 

Tailor> COPY /FILE CDU 

Tailor> COPY /FILE DIFF 

Tailor> COPY /FILE SEARCH 

Tailor> COPY /FILE [SYSHLP]HELPLIB.HLP 

Tailor> EXIT 

6 End tailoring with the EXIT command: 

Tailor> EXIT 

See the Guide to VAX/VMS Software Installation for more information on 
running the UETP. 


3.4.2 Enabling Job Queues 

Job queues are disabled by default. If you wish to create queues, use the 
following commands to copy the QUEUES tailoring group to your system 
disk: 

Tailor> MOUNT ddcu: 

Tailor> COPY QUEUE 
Tailor> EXIT 

Then shut down and reboot as described in Section 2.7. 

Approximately 100 blocks are required to create the system queue file 
(SYS$SYSTEM:JBCSYSQUE.EXE). See Section 9 for more information about 
creating and managing queues. 
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3.4.3 Analyzing System Failures 

The VAX/VMS operating system includes a capability for writing crash 
dumps to your system disk when a serious hardware or software problem 
occurs. Usually a dump file (SYS$SYSTEM:SYSDUMP.DMP) is required 
equal in size to the number of pages of physical memory on your system 
plus four blocks. However, in small-disk systems, crash dumps are written 
instead to the system paging file (SYS$SYSTEM:PAGEFILE.SYS). Normally 
the dumps are overwritten each time you boot your system. To preserve 
crash dumps for analysis, you set the SYSGEN parameter SAVEDUMP to 1 
and copy the dump to another disk. These operations are described in the 
next sections. 


3.4.3.1 Setting the SAVEDUMP Parameter 

For small-disk systems, the SAVEDUMP parameter is off by default. If you 
wish to preserve crash dumps on a routine basis, you set the parameter to 1. 
Note, however, that if your system fails and the parameter is set to 0, you 
may still preserve the dump by stopping in SYSBOOT when you reboot your 
system and setting the SAVEDUMP parameter to 1. (See Section 4.2.3 for 
instructions on booting and stopping in SYSBOOT.) 

To set the SAVEDUMP parameter while running interactively, invoke 
SYSGEN as follows: 

$ RUN SYSISYSTEM:SYSGEN 

Modify the SAVEDUMP parameter by typing the following commands at the 
successive SYSGEN prompts: 

SYSGEN> USE CURRENT 
SYSGEN> SET SAVEDUMP 1 
SYSGEN> WRITE CURRENT 
SYSGEN> EXIT 

Shut down and reboot as described in Section 2.7. 


3.4.3.2 Saving the Dump for Analysis 

Since a large portion of your paging file becomes unavailable when a dump 
is saved, it is necessary to free this space as quickly as possible. Your system 
may perform very slowly, or even fail again, when only a small amount of 
paging file space is available. If less than 1000 blocks of paging file remain, 
the SAVEDUMP parameter is ignored, and the dump is deleted immediately. 

To ensure that dumps are automatically copied to another disk and that space 
is reclaimed in the paging file, place the following commands in your site- 
specific startup command procedure (SYS$MANAGER:SYSTARTUP.COM). 
(These commands assume the presence of a data disk on device DQA1 with a 
volume label USERDISK and a directory of [CRASH].) 

MOUNT DQA1: USERDISK 

ANALYZE /CRASH SYS$SYSTEM:PAGEFILE.SYS 

COPY DQA1:[CRASH]SYSDUMP.DMP;1 

EXIT 

After the disk is mounted, the System Dump Analyzer (SDA) is invoked. 
SDA then acts as follows to manage a crash dump: 

1 Exits immediately when invoked from the startup command procedure if 
one of the following is true: 

a The dump file contains no valid dump. 

b The dump has been previously analyzed. 
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c The dump is the result of an operator-requested shutdown. 

2 Frees the paging file space for immediate use at the successful completion 
of a COPY operation. 

3 When the dump is copied to an already existing file, replaces that file 
rather than creating a new one. By explicitly specifying a version number 
of 1, each new crash dump replaces any older crash dump already saved 
on the user disk. 

If you cannot boot or successfully copy a crash dump, you may boot another 
system disk, mount the system disk containing the dump as a data disk, and 
then analyze the crash dump. 


3.4.4 Installing Image Files with Privileges 

The library files listed in Table 3-3 must be installed with privileges on 
small-disk systems for proper operation. 


Table 3-3 Files Requiring Installation with Privileges 


File 

File Group 

AUTHORIZE.EXE 

MANAGER 

ANALIMDMP.EXE 

DEVELOP 

INIT.EXE 

MANAGER 

SHWCLSTR.EXE 

MISCTOOLS 

MAIL.EXE 

MISCTOOLS 

PHONE.EXE 

MISCTOOLS 

RTPAD.EXE 

DECNET 

CDU.EXE 

MISCTOOLS 

MONITOR.EXE 

MISCTOOLS 

SUBMIT.EXE 

QUEUES 

DBGSSISHR.EXE 

DEVELOP 


If you bootstrap your system with these files already tailored to your system 
disk, they will be installed automatically. If you tailor them to your system 
disk after bootstrapping, you can install them in one of two ways: 

• You may shut your system down, using SYS$SYSTEM:SHUTDOWN, and 
reboot as described in Section 2.7. 

• You may invoke the DIGITAL image installation procedure with the 
following command: 

$ <BSYS$MANAGER:VMSIMAGES INSTALL VMSIMAGES 

For further information about installed images, see Section 8. 
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3.4.5 Copying Images Needed for DCL Commands to the System Disk 

Many DCL commands activate a related VAX/VMS image. For example, the 
DCL command LIBRARY normally calls the image LIBRARIAN. In a small- 
disk environment, you cannot invoke an image that is not already tailored to 
your system environment. If you attempt to do so, you will receive one of 
the following error messages: 

'/.DCL-W-ACTIMAGE, error activating image 'name' 

-CLI-E-IMAGEFNF, image file not found 'image name' 

Before invoking the image, you must use the tailoring COPY command to 
copy the appropriate image file or file group from the library disk to the 
system disk. 

Table 3-4 lists commands that invoke an image, the image activated, and 
the file group in which it is present. The table also shows how command 
qualifiers may change the image call. 

Note: The relationship between DCL commands and invoked images shown in 
the table is specific to Version 4.0 of the VAX/VMS operating system and 
is provided only as a guide for tailoring your system disk. You should 
avoid writing programs or procedures that depend on this relationship, 
because it changes from release to release. 


Table 3-4 DCL Commands, Activated Images, and File Groups 


Command 

Image 

File Group 

ACCOUNTING 

ACC 

MANAGER 

ANALYZE 

ANALYZOBJ 

FILETOOLS 

/CRASH _DUMP 

SDA 1 

MISCTOOLS 

/DISK_STRUCTURE 

VERIFY 

MANAGER 

/ERROR_LOG 

ERF 

MISCTOOLS 

/MEDIA 

ANALYZBAD 

MANAGER 

/PROCESS-DUMP 

ANALIMDMP 

DEVELOP 

/RMS—FILE 

ANALYZRMS 

FILETOOLS 

/SYSTEM 

SDA 1 

MISCTOOLS 

APPEND 

COPY 

REQUIRED 

ASSIGN 

DCL 

REQUIRED 

/MERGE 

QUEMAN 

QUEUES 

/QUEUE 

QUEMAN 

QUEUES 

BACKUP 

BACKUP 

REQUIRED 

CHECKSUM 

CHECKSUM 

MISCTOOLS 

CONVERT 

CONVERT, CONVSHR 

FILETOOLS 

/RECLAIM 

RECLAIM, CONVSHR 

FILETOOLS 

COPY 

COPY 

REQUIRED 

CREATE 

CREATE 

REQUIRED 

/FDL 

CREATEFDL, CONVSHR 

FILETOOLS 

DEASSIGN 

DCL 

REQUIRED 


1 SYS.STB required (LIBRARY file group). 
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Table 3-4 (Cont.) DCL Commands, Activated Images, and File Groups 


Command 

Image 

File Group 

/QUEUE 

QUEMAN 

QUEUES 

DEFINE 

DCL 

REQUIRED 

/CHARACTERISTIC 

QUEMAN 

QUEUES 

/FORM 

QUEMAN 

QUEUES 

DELETE 

DELETE 

REQUIRED 

/CHARACTERISTIC 

QUEMAN 

QUEUES 

/ENTRY 

QUEMAN 

QUEUES 

/FORM 

QUEMAN 

QUEUES 

/QUEUE 

QUEMAN 

QUEUES 

DIFFERENCES 

DIFF 

TEXTTOOLS 

DIRECTORY 

DIRECTORY 

REQUIRED 

DISMOUNT 

DISMOUNT, DISMNTSHR 

REQUIRED 

DUMP 

DUMP 

FILETOOLS 

EDIT 

EDT 

TEXTTOOLS 

/ACL 

ACLEDT 

FILETOOLS, MANAGER 

/FDL 

EDF, FDLSHR 

FILETOOLS 

/SUM 

SUMSLP, SUMSHR 

TEXTTOOLS 

/TECO 

TECO 

TEXTTOOLS 

EXCHANGE 

EXCHANGE 

MANAGER 

HELP 

HELP 2 

REQUIRED 

INITIALIZE 

INIT 

MANAGER 

/BASE_PRIORITY 

QUEMAN 

QUEUES 

/BATCH 

QUEMAN 

QUEUES 

/BLOCK_LIMIT 

QUEMAN 

QUEUES 

/CHARACTERISTICS 

QUEMAN 

QUEUES 

/CPUDEFAULT 

QUEMAN 

QUEUES 

/CPUMAXIMUM 

QUEMAN 

QUEUES 

/DEFAULT 

QUEMAN 

QUEUES 

/DISABLE—SWAPPING 

QUEMAN 

QUEUES 

/ENABLE—GENERIC 

QUEMAN 

QUEUES 

/FORM 

QUEMAN 

QUEUES 

/GENERIC 

QUEMAN 

QUEUES 

/JOB-LIMIT 

QUEMAN 

QUEUES 

/LIBRARY 

QUEMAN 

QUEUES 

/ON 

QUEMAN 

QUEUES 

/PROCESSOR 

QUEMAN 

QUEUES 

/QUEUE 

QUEMAN 

QUEUES 

/RETAIN 

QUEMAN 

QUEUES 


2 HELPLIB.LIB required (HELP file group). 
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Table 3-4 (Cont.) DCL Commands, Activated Images, and File Groups 


Command 

Image 

File Group 

/SEPARATE 

QUEMAN 

QUEUES 

/START 

QUEMAN 

QUEUES 

/TERMINAL 

QUEMAN 

QUEUES 

/WINDOWS 

QUEMAN 

QUEUES 

/WSDEFAULT 

QUEMAN 

QUEUES 

/WSEXTENT 

QUEMAN 

QUEUES 

/WSQUOTA 

QUEMAN 

QUEUES 

LIBRARY 

LIBRARIAN 

DEVELOP 

LINK 

LINK 3 

CRFSHR 

MACRO 

MACR032 4 , SUMSHR 

DEVELOP 

MAIL 

MAIL, CONVSHR, EDTSHR 

MISCTOOLS 

MERGE 

MERGE 

MISCTOOLS 

MESSAGE 

MESSAGE 

MISCTOOLS 

MONITOR 

MONITOR 

MISCTOOLS 

MOUNT 

VMOUNT, MOUNTSHR 

REQUIRED 

PATCH 

PATCH 

MISCTOOLS 

PHONE 

PHONE 

MISCTOOLS 

PRINT 

SUBMIT 

QUEUES 

PURGE 

DELETE 

REQUIRED 

RENAME 

RENAME 

REQUIRED 

REPLY 

REPLY 

REQUIRED 

REQUEST 

REQUEST 

REQUIRED 

RUN 

DCL 

REQUIRED 

/ACCOUNTING 

RUNDET 

REQUIRED 

/AST_LIMIT 

RUNDET 

REQUIRED 

/AUTHORIZE 

RUNDET 

REQUIRED 

/BUFFER_LIMIT 

RUNDET 

REQUIRED 

/DELAY 

RUNDET 

REQUIRED 

/DETACHED 

RUNDET 

REQUIRED 

/DUMP 

RUNDET 

REQUIRED 

/ENQUEUE_LIMIT 

RUNDET 

REQUIRED 

/ERROR 

RUNDET 

REQUIRED 

/EXTENT 

RUNDET 

REQUIRED 

/FILE—LIMIT 

RUNDET 

REQUIRED 

/INPUT 

RUNDET 

REQUIRED 

/INTERVAL 

RUNDET 

REQUIRED 

/IO—BUFFERED 

RUNDET 

REQUIRED 


3 STARLET.OLB and IMAGELIB.OLB required (LIBRARY file group). 
“SYS.STB required (LIBRARY file group). 
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Table 3-4 (Cont.) DCL Commands, Activated Images, and File Groups 


Command 

Image 

File Group 

/IO_DIRECT 

RUNDET 

REQUIRED 

/JOB_T ABLE_QUOT A 

RUNDET 

REQUIRED 

/MAILBOX 

RUNDET 

REQUIRED 

/MAXIMUM_WORKING_SET 

RUNDET 

REQUIRED 

/OUTPUT 

RUNDET 

REQUIRED 

/PAGE_FILE 

RUNDET 

REQUIRED 

/PRIORITY 

RUNDET 

REQUIRED 

/PRIVILEGES 

RUNDET 

REQUIRED 

/PROCESS 

RUNDET 

REQUIRED 

/QUEUE-LIMIT 

RUNDET 

REQUIRED 

/RESOURCE_WAIT 

RUNDET 

REQUIRED 

/SCHEDULE 

RUNDET 

REQUIRED 

/SERVICE_FAILURE 

RUNDET 

REQUIRED 

/SUBPROCESS—LIMIT 

RUNDET 

REQUIRED 

/SWAPPING 

RUNDET 

REQUIRED 

/UIC 

RUNDET 

REQUIRED 

RUNOFF 

RUNOFF 

TEXTTOOLS 

/CONTENTS 

DSRTOC 

TEXTTOOLS 

/INDEX 

DSRINDEX 

TEXTTOOLS 

SDL/NOPARSE 

SDLNPARSE 

DEVELOP 

SEARCH 

SEARCH 

TEXTTOOLS 

SET 

SET 

REQUIRED 

ACCOUNTING 

SET 

REQUIRED 

ACL 

SETSHOACL 

FILETOOLS, MANAGER 

/EDIT 

ACLEDT 

FILETOOLS, MANAGER 

AUDIT 

SET 

REQUIRED 

BROADCAST 

SET 

REQUIRED 

CARD_READER 

SET 

REQUIRED 

CLUSTER 

SET 

REQUIRED 

COMMAND 

CDU 

MISCTOOLS 

DAY 

SET 

REQUIRED 

DEVICE 

SET 

REQUIRED 

/ACL 

SETSHOACL 

FILETOOLS, MANAGER 

/EDIT 

ACLEDT 

FILETOOLS, MANAGER 

DIRECTORY 

SET 

REQUIRED 

/ACL 

SETSHOACL 

FILETOOLS, MANAGER 

/EDIT 

ACLEDT 

FILETOOLS, MANAGER 

FILE 

SET 

REQUIRED 

/ACL 

SETSHOACL 

FILETOOLS, MANAGER 
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Table 3-4 (Cont.) DCL Commands, Activated Images 

r and File Groups 

Command 

Image 

File Group 

/EDIT 

ACLEDT 

FILETOOLS, MANAGER 

HOST 

RTPAD 

DECNET 

LOGINS 

SET 

REQUIRED 

MAGTAPE 

SET 

REQUIRED 

MESSAGE 

SETPO 

REQUIRED 

PASSWORD 

SETPO 

REQUIRED 

PRINTER 

SET 

REQUIRED 

PROCESS 

SET 

REQUIRED 

PROTECTION 

SET 

REQUIRED 

QUEUE 

QUEMAN 

QUEUES 

REST ART_VALUE 

QUEMAN 

QUEUES 

RMS_DEFAULT 

SET 

REQUIRED 

TERMINAL 

SET 

REQUIRED 

VOLUME 

SET 

REQUIRED 

WORKING-SET 

SET 

REQUIRED 

SHOW 

SHOW 

REQUIRED 

ACCOUNTING 

SHOW 

REQUIRED 

ACL 

SETSHOACL 

FILETOOLS, MANAGER 

AUDIT 

SHOW 

REQUIRED 

BROADCAST 

SHOW 

REQUIRED 

CLUSTER 

SHWCLSTR 

MISCTOOLS 

CPU 

MP 

REQUIRED 

DEVICES 

SHOW 

REQUIRED 

ERROR 

SHOW 

REQUIRED 

LOGICAL 

SHOW 

REQUIRED 

MAGTAPE 

SHOW 

REQUIRED 

MEMORY 

SHOW 

REQUIRED 

NETWORK 

SHOW 

REQUIRED 

PRINTER 

SHOW 

REQUIRED 

PROCESS 

SHOW 

REQUIRED 

QUEUE 

QUEMAN 

QUEUES 

RMS_DEFAULT 

SHOW 

REQUIRED 

SYSTEM 

SHOW 

REQUIRED 

TERMINAL 

SHOW 

REQUIRED 

USERS 

SHOW 

REQUIRED 

WORKING-SET 

SHOW 

REQUIRED 

SORT 

SORTMERGE 

MISCTOOLS 

START 

QUEMAN 

QUEUES 

/CPU 

MP 

REQUIRED 
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Table 3-4 (Cont.) 

DCL Commands, Activated Images 

r and File Groups 

Command 

Image 

File Group 

STOP 

DCL 

REQUIRED 

/ABORT 

QUEMAN 

QUEUES 

/CPU 

MP 

REQUIRED 

/ENTRY 

QUEMAN 

QUEUES 

/HOLD 

QUEMAN 

QUEUES 

/MANAGER 

QUEMAN 

QUEUES 

/NEXT 

QUEMAN 

QUEUES 

/PRIORITY 

QUEMAN 

QUEUES 

/QUEUE 

QUEMAN 

QUEUES 

/REQUEUE 

QUEMAN 

QUEUES 

/RESET 

QUEMAN 

QUEUES 

SUBMIT 

SUBMIT 

QUEUES 

SYNCHRONIZE 

QUEMAN 

QUEUES 

TYPE 

TYPE 

REQUIRED 

UNLOCK 

UNLOCK 

FILETOOLS 


3.5 Error and Informational Messages from the Tailoring Facility 

This section lists the error and informational messages issued by the 
Tailoring facility. Each message consists of an abbreviation followed by a 
text message. 

AMBIGRP, 'group name' is an ambiguous group name 

Explanation: The group name as entered has too few characters to make it 
unique. 

User Action: Reenter the command with a unique group name. 

AMBIGWRD, 'word' is an ambiguous word 

Explanation: The abbreviated command or qualifier is ambiguous. 

User Action: Reissue the command specifying a long enough spelling to 
resolve the ambiguity. 

BADCOMMA, invalid comma in command 

Explanation: A comma has been detected preceding the first parameter in a 
command. 

User Action: Correct the command and reissue. 

CTRLY, function aborted by CTRL/Y 

Explanation: The function in progress has been interrupted by pressing the 
CTRL and Y keys simultaneously. 

User Action: None. 
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DEVICEREQ, device must be specified 

Explanation: A device name was not specified with this command. 

User Action: Reenter the command specifying a device name. 

DISMOUNT, device dismounted 

Explanation: The library disk has been dismounted. 

User Action: None. 

EXPNOTFND, expected file 'filename' not found 

Explanation: A file with the specified name could not be found during an 
open operation. 

User Action: Examine the referenced directory to check for the existence of 
the named file. Check the spelling of the file specification. 

FILENAMEREQ, a file name must be specified 

Explanation: A file name must be specified with this command. 

User Action: Reissue the command, specifying a file name. 

GROUPREQ, a group must be specified 

Explanation: A group name must be specified with this command. 

User Action: Reissue the command, specifying a group name. 

F1ELPGROUPS, type DIR/GROUPS for a list of tailoring groups 

Explanation: This is an informational message issued when an invalid group 
name is used. 

User Action: Use the DIRECTORY/GROUPS tailoring command to obtain a 
list of valid group names. 

HELPVERB, type HELP 'command' 

Explanation: This is an information message issued when a command is 
improperly used. 

User Action: Use the HELP command to obtain more information. 

HLPMOUNTWRT, type HELP MOUNT/WRITE 

Explanation: Issued following a write-lock error. 

User Action: Use the indicated HELP command to obtain more information 
about mounting disks writeable. 

LIBNOTMOUNT, the LIBRARY disk must be mounted 

Explanation: A command has been issued that requires the library disk. 

User Action: Mount the library disk and reissue the command. 
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LIBPROTECT, the LIBRARY disk must be writeable 

Explanation: A write-lock error message has occurred on the library disk as 
the result of a command directing the Tailoring facility to write to the library 
disk. 

User Action: Check that write protect is disabled, mount the library disk 
writeable, and reissue the command. 

NOBACKUP, no backup copy on device 'device' 

Explanation: A request to delete a file has been ignored because the file has 
no backup copy on the library disk (or on the system disk if the /LIBRARY 
qualifier has been specified). 

User Action: Check that the file exists on the backup disk, and that the file 
name is properly spelled. 

NOHELP, help not available 

Explanation: Either the Help Utility or the Tailoring help library could not 
be located on the system disk or, if it is mounted, on the library disk. 

User Action: Mount the library disk and reissue the command. If the 
library disk is already mounted, then this error indicates that files have 
been improperly deleted from one or both disks. 

NONZEROREF, open files on device, not dismounted 

Explanation: The library disk cannot be dismounted because of open 
channels to the device. 

User Action: Investigate the list of files displayed, using the process ID field, 
to determine what users or batch jobs have files open. Close the files and 
reissue the DISMOUNT command. 

NOQUAL, no qualifiers allowed on the 'command' command 

Explanation: No qualifiers are allowed on the indicated command. 

User Action: Check the typing of the command. Type HELP to obtain more 
information about the syntax of the command. 

NOSEARCH, SEARCH not available 

Explanation: The SEARCH.EXE file could not be located on the system disk 
or, if it is mounted, on the library disk. 

User Action: Mount the library disk and reissue the command. If the library 
disk is already mounted, this error indicates that files have been improperly 
deleted from one or both disks. 

NOSUCHDEV, no such device as 'device' 

Explanation: The specified device does not exist. 

User Action: Check the spelling of the device name. Use the DCL command 
SHOW DEVICES to obtain a list of valid devices. 
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NOSUCHDIR, expected directory 'directory' not found 

Explanation: The specified directory was not found. 

User Action: Check the spelling of the file specification used in the 
command. If correct, use the DCL command DIRECTORY to check if the 
directory exists. 

NOSUCHFILE, no files matching the specification 'filename' were found 

Explanation: No files could be located that matched the indicated file 
specification. 

User Action: Check the spelling of the file name. Use the DCL DIRECTORY 
command to look for the indicated files. 

NOSUCHGROUP, group file 'group name' not found 

Explanation: The specified group could not be found. 

User Action: Check the spelling of the group name. Use the DIRECTORY 
/GROUP tailoring command to obtain a list of groups. 

NOTDELETED, 'filename' not deleted 

Explanation: The indicated file name was not deleted. This is an 
informational message that accompanies an error message explaining the 
reason for the delete failure. 

User Action: Investigate the associated error message. 

NOWILDCARDS, wildcards not allowed in group names 

Explanation: Wildcards (* and %) are not allowed in the specification of 
group names. 

User Action: Reissue the command with an explicit group name. 

NO WRITE, device is not write enabled 

Explanation: An attempt to mount the library disk /WRITE has failed. 

User Action: Check that the disk is not write protected. Retry the command. 

OPENIN, error opening 'filename' as input 

Explanation: The indicated input file could not be opened. 

User Action: Check that the file exists and that you have read access to it. 

OPENOUT, error opening 'filename' as output 

Explanation: The indicated output file could not be opened. 

User Action: Check that the directory exists and that you have write access 
to it. 

REISSUE, correct the situation and reissue the command 

Explanation: This informational message is issued in conjunction with other 
error messages. 

User Action: Address the problem described by the associated error message 
and reissue the command. 
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REQNOTALLOWED, the REQUIRED file group cannot be deleted 

Explanation: An attempt was made to delete the REQUIRED file group. 

User Action: None. The REQUIRED file group is needed to boot the system 
and cannot be deleted. 

TOOMANYPARM, too many parameters 

Explanation: More than the maximum number of parameters have been 
given on a command line. 

User Action: Check the spelling of the command. If correct, then break the 
command into several simpler commands having fewer parameters. 

UNRECCMC, 'command' is an unrecognized command 

Explanation: The indicated command is not a valid command. 

User Action: Use the HELP command to obtain a list of valid commands. 

UNRECQUAL, 'qualifier' not valid for this command 

Explanation: The specified qualifier is not valid for the command issued. 

User Action: Check the spelling of the qualifier and the command. Use 
the HELP command to obtain the proper spellings. Note that the Tailoring 
facility checks the entire spelling of keywords, unlike DCL, which checks only 
the first four characters. 

USEEXIT, type EXIT to exit 

Explanation: An attempt to terminate tailoring is invalid. 

User Action: Use the EXIT command to exit. 

USEHELP, type HELP for more information 

Explanation: This informational message is issued in association with various 
error messages. 

User Action: Use the HELP command to obtain more information about 
the command you are using. For example, if an error occurs on a COPY 
command, then type HELP COPY. 
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Shutdown and Startup 


During the course of system operation, you will need to shut down and 
restart your system to perform various maintenance functions. For example, 
you may need to modify system parameters or make certain hardware 
modifications. Also, if the system fails and does not automatically restart, you 
will need to bootstrap the system manually to restart it. DIGITAL provides 
several procedures for shutting down and restarting the system. This chapter 
describes these procedures. 


4.1 Shutting Down the Operating System 

You can perform three types of shutdown operations: 

1 An orderly shutdown with SYS$SYSTEM:SHUTDOWN.COM. This 
procedure shuts down the system while performing housekeeping 
functions such as disabling future logins, stopping the batch and printer 
queues, dismounting mounted volumes, and stopping user processes. 
SHUTDOWN.COM is described in Section 4.1.1. 

SHUTDOWN.COM optionally invokes a site-specific command procedure 
named SYS$MANAGER:SYSHUTDWN.COM, which you tailor to the 
needs of your installation. The SYSHUTDWN.COM file is present in the 
VAX/VMS distribution kit but contains no commands. 

2 An emergency shutdown with OPCCRASH. If you cannot shut down 
the system with SHUTDOWN.COM, you run the OPCCRASH emergency 
shutdown program. OPCCRASH is described in Section 4.1.2. 

3 An emergency shutdown with CRASH. You use this procedure for an 
emergency shutdown of the system if OPCCRASH fails. On all VAX 
processors except the VAX-11/750, the procedure is supplied on the 
system console medium as a console command program named CRASH. 
Sections 4.1.3, 4.1.4, and 4.1.5 describe the CRASH procedures for specific 
VAX processors. 


4.1.1 Orderly Shutdown with SHUTDOWN.COM 

This section describes the use of SHUTDOWN.COM to shut down the system 
in an orderly fashion. Do not modify SHUTDOWN.COM; instead, you 
can add commands to the SYS$MANAGER:SYSHUTDWN.COM command 
procedure to perform site-specific housekeeping functions. 

To execute SHUTDOWN.COM, you must have either the SETPRV privilege 
or all the following privileges: CMKRNL, EXQUOTA, OPER, SYSNAM, 
SYSPRV, TMPMBX, and WORLD. If you have the SETPRV privilege, the 
procedure will automatically assign you the required privileges. 

To perform an orderly shutdown of the system, invoke SHUTDOWN.COM 
from any terminal and any account with the following DCL command: 

$ ®SYS$SYSTEM:SHUTDOWN 
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The procedure then prompts with a series of questions and messages. These 
are shown below, along with directions for appropriate responses. 

How many minutes until final shutdown [0]? 

Enter an integer. If the system logical name SHUTDOWN$MINIMUM_ 
MINUTES is defined, its integer value is the minimum value that you can 
enter. Therefore, if the logical name is defined as 10, you must specify at 
least 10 minutes to final shutdown or an error message is returned. If you do 
not enter a value, the logical name value is used. If the logical name is not 
defined, and you do not enter a value, 0 minutes is the default. 

Reason for shutdown: 

Enter a one-line reason for shutting down the system. The default response is 
"standalone". 

Do you want to spin down the disk volumes [No]? 

Enter YES or NO (Y or N). Note, however, that the system disk cannot be 
spun down. 

Do you want to invoke the site-specific shutdown procedure [Yes]? 

Enter YES or NO. This refers to SYS$MANAGER:SYSHUTDWN.COM. 

Should an automatic system boot be performed [No]? 

By default, the system does not automatically reboot. However, if you 
respond with YES, when the shutdown is complete, an attempt is made to 
reboot the system automatically. Note that the system can be automatically 
rebooted only if the appropriate hardware switch is also set on the processor, 
and if the default bootstrap command file is properly set. See Section 2.4 for 
a description of how to set the default bootstrap command file. 

When will the system be rebooted [later]? 

Enter a time in the format you want printed in the message that will be 
broadcast to users. For example, you could specify IMMEDIATELY, or IN 10 
MINUTES, or a time such as 2 P.M. or 14:00. If you do not know when the 
system will be available again, press RETURN to specify "later" as the time 
when the system will reboot. 

Shutdown options (enter as a comma-separated list): 

REM0VE.N0DE Remaining nodes in the cluster should adjust quorum 

CLUSTER.SHUTDOWN Entire cluster is shutting down 
REBOOT.CHECK Check existence of basic system files 

Shutdown options [NONE] 

The procedure prompts you to specify one or more shutdown options. If 
your system is a VAXcluster member, all three options are listed. (For more 
information on cluster shutdown options, see the Guide to VAXclusters.) 
Otherwise, only the REBOOT_CHECK option is listed. Enter 
REBOOT_CHECK if you wish to verify that a subset of the files necessary to 
reboot the system after shutdown is present. (If you are certain that the files 
exist, press RETURN.) 

If you select the REBOOT_CHECK option, the procedure will check for the 
necessary files and notify you if any are missing. (Note, however, that this 
check is not exhaustive.) You should replace missing files before proceeding. 
If all files are present, this success message appears: 

'/.SHUTDOWN -1-CHECK0K, Basic reboot consistency check completed. 
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The following events occur as the shutdown procedure continues, and the 

corresponding messages are printed on the terminal: 

1 A message that requests users to log out is broadcast to all users on the 
system. This message is broadcast at decreasing time intervals. 

2 The system logical name SHUTDOWN$TIME is defined as the absolute 
time of shutdown. For example, if the value 10 is specified at 12:00 in 
response to the first question, the logical name is assigned the absolute 
time value 12:10 along with the date. By requesting the logical name 
definition for SHUTDOWN$TIME (with the SHOW LOGICAL command), 
you can see if a shutdown is in progress or determine the actual time of 
shutdown. This feature is useful if a user for some reason missed the 
shutdown broadcast message. 

3 At six minutes or less until system shutdown, the terminal from 
which shutdown was invoked is made an operator's console, all future 
nonoperator logins are disabled, and if the DECnet network is running, it 
is shut down. 

4 When there is one minute left until system shutdown, batch and device 
queues and the system job queue manager are stopped. 

5 At zero minutes, the site-specific command procedure 
SYS$MANAGER:SYSHUTDWN.COM is invoked. 

6 All user processes are stopped; however, system processes continue. 

ACPs may delete themselves when their mounted volumes are finally 
dismounted. 

7 For dual-processor systems, the secondary processor is stopped. 

8 All installed images are removed. 

9 All mounted volumes are dismounted and, if you request it, the disks are 
spun down. Note, however, that the system disk cannot be spun down. 

10 The operator's log file is closed. 

11 The program SYS$SYSTEM:OPCCRASH is invoked to shut down the 
system. 

12 If you did not request an automatic reboot, the following message appears 
on the system console: 

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM 

If you requested an automatic reboot, the system reboots, provided the 
necessary controls are set. 

1 3 If you are not automatically rebooting, you must halt the system after the 
above message is printed at the console terminal. 

Example 4-1 demonstrates an orderly system shutdown on standalone node 

AVALON. 
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Example 4-1 Orderly System Shutdown with 
SHUTDOWN.COM 


$ <OSYS$SYSTEM: SHUTDOWN 

SHUTDOWN -- Perform an Orderly System Shutdown 
How many minutes until final shutdown [0]: 10 

Reason for shutdown: [Standalone] MONTHLY PREVEN TIVE MAINTENANCE. 

Do you want to spin down the disk volumes [No]? 1 RET| _ 

Do you want to invoke the site-specific shutdown pr ocedu re [Yes]? I RET| 

Should an automatic system boot be performed [No]? 1 RET| 

When will the system be rebooted [later]? 12:30 
Shutdown options: 

REBOOT.CHECK Che ck ex istence of basic system files 

Shutdown options [NONE] I RET1 

SHUTDOWN message on AVALON, from user SYSTEM at _AVALON$OPAO: 12:00:00.20 

AVALON will shut down in 10 minutes; back up 12:30. Please log off node AVALON. 
MONTHLY PREVENTIVE MAINTENANCE 

'/.SHUTDOWN-1-OPERATOR, This terminal is now an operator's console. 

xxxxxxxxxxx opcom , ie- jun- lose 12 : 01 : 00 . i5 rammn 

Operator status for operator _AVAL0N$0PA0: 

CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS. NETWORK, 0PER1. 0PER2, 

0PER3, 0PER4, 0PER5, 0PER6, 0PER7, 0PER8, 0PER9, 0PER10, 0PER11, 

0PER12 

'/.SHUTDOWN-1-DISLOGINS, Interactive logins will now be disabled. 
y.SET-I-INTSET, login interactive limit = 0 current interactive value ■ 17 
'/.SHUTDOWN-1-SHUTNET, The DECnet network will now be shut down. 

'/.SHUTDOWN-1-STOPQUEMAN, The queue manager will now be stopped. 

SHUTDOWN message on AVALON, from user SYSTEM at _AVALON$OPAO: 12:05:00.20 

AVALON will shut down in 5 minutes; back up 12:30. Please log off node AVALON. 
MONTHLY PREVENTIVE MAINTENANCE 

17 terminals have been notified on AVALON. 

SHUTDOWN message on AVALON from user SYSTEM at _AVAL0N$0PA0: 12:06:55.28 

AVALON will shut down in 4 minutes; back up 12:30. Please log off node AVALON. 
MONTHLY PREVENTIVE MAINTENANCE 

mmmxx OPCOM. 16-JUN-1986 12:07:12.30 XXXXXXXXXXX 

Message from user DECnet on AVALON 

DECnet event 2.0, local node state change 

From node 2.161 (AVALON). 16-JUN-1986 12:07:22.26 

Operator command. Old state = On, New state = Shut 

SHUTDOWN message on AVALON from user SYSTEM at _AVALON$OPAO: 12:07:12.56 

AVALON will shut down in 3 minutes; back up 12:30. Please log off node AVALON. 
MONTHLY PREVENTIVE MAINTENANCE 

7.SHUTD0WN-1-STOPQUEMAN, The queue manager will now be stopped. 

SHUTDOWN message on AVALON user SYSTEM at _AVAL0N$0PA0: 12:08:12.56 

AVALON will shut down in 2 minutes; back up 12:30. Please log off node AVALON. 
MONTHLY PREVENTIVE MAINTENANCE 

XXXXXXXXXXX OPCOM, 16-JUN-1986 12:08:12:30 XXXXXXXXXXX 
Message from user JOB.CONTROL on AVALON 
-SYSTEM-S-NORMAL, normal successful completion 

XXXXXXXXXXX OPCOM. 16-JUN-1986 12:08:42.30 XXXXXXXXXXX 
Message from user DECNET on AVALON 
DECnet shutting down 

SHUTDOWN message on AVALON from user SYSTEM at _AVAL0N$0PA0: 12:09:12.56 

AVALON will shut down in 1 minute; back up 12:30. Please log off node AVALON. 
MONTHLY PREVENTIVE MAINTENANCE 


(Continued on next page) 
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Example 4-1 (Cont.) Orderly System Shutdown with 

SHUTDOWN.COM 


17 terminals have been notified on AVALON 

'/.SHUTDOWN-1-SITESHUT, The site-specific shutdown procedure will now be invoked. 
7.SHUTD0WN -1 - STOPUSER, All user processes will now be stopped. 

'/.SHUTDOWN-1-REMOVE, All installed images will now be removed. 

'/.SHUTDOWN-1-DISMOUNT, All volumes will now be dismounted. 

y.'/.'/.'/.y.y.'/.y.y.y.y. opcom, ig-jun-ioso 12 : 09 : 42.30 uunxnn 

Message from user System on AVALON 

_AVALON$OPAO:, AVALON shutdown was requested by the operator. 

y.y.y.y.y.*/.y.y.y.y.y. opcom. i6-jun-i986 12 : 10 : 02.44 y.'/.y.y.y.y.y.y.y.y.y. 

Logfile was closed by operator _AVALON$OPAO: 

Logfile was SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;8 

•/.y.y.y.y.y.y.y.y.'/.y. opcom, i6-jun-i986 12 : 10 : 32.20 nmnnn 

Operator _AVALON$OPAO: has been disabled, username SYSTEM 

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM 


4.1.2 Emergency Shutdown with OPCCRASH 

This section describes how to halt the system immediately without performing 
any of the housekeeping functions that ensure an orderly shutdown. 
Generally, you should shut down the system by following the orderly 
shutdown procedure described in Section 4.1.1, because since OPCCRASH 
performs only minimal housekeeping functions, data may be lost. 

To perform this procedure, you must have the CMKRNL privilege. You can 
enter the commands from any terminal and any account. 

1 Enter the following command to force an immediate shutdown of the 
system: 

$ RUN SYSISYSTEM:OPCCRASH 

2 If the system fails to respond after a few minutes, use the alternate 
crash procedure appropriate for your VAX processor, as described in 
Sections 4.1.3 and 4.1.5. 

3 At the system console, observe the following message: 

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM 

4 Now halt the system. You halt a VAX-11/730, 11/750, or Micro VAX 
system by pressing CTRL/P. To halt a VAX-11/780 system or other VAX 
processor, press CTRL/P to obtain the console prompt (> > > ), and 
then type HALT. 

Example 4-2 illustrates an emergency shutdown on a VAX-11/780 using the 
OPCCRASH procedure. 

Example 4-2 Emergency Shutdown on a VAX-11/780 Using 
OPCCRASH 


$ RUN SYS$SYSTEM:OPCCRASH 

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM 

| CTRL/P 1 

>»HALT 

HALTED AT 8000708A 
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4.1.3 Emergency Shutdown with CRASH on VAX—11/730, VAX—11/780 
Systems 

This section describes the CRASH console program command procedure that 
forces a VAX-11/780 or VAX-11/730 system to fail, resulting in immediate 
shutdown. Procedures for performing the equivalent operation on 
VAX-11/750 and VAX 8600 systems are described in the following sections. 

Note: You should use CRASH only if the system will not accept command 
input; that is, if the system fails to accept or respond to OPCCRASH. 

You must issue all commands that invoke CRASH from the system console 
terminal. 

To force a VAX-11/780 or a VAX-11/730, system to fail with CRASH, 
proceed as follows: 

1 Halt the system. You halt a VAX-11/730 system by pressing CTRL/P. To 
halt all other VAX processors, press CTRL/P to obtain the console prompt 
(> > > ), and then type HALT. 

2 At the console prompt, type 

»> (DCRASH 

This command invokes the CRASH console program command file. 

3 Additional messages and information, such as the fatal bugcheck message, 
are printed at the console terminal. A dump of memory is written to the 
system dump file on disk. 

Example 4-3 illustrates the procedure for a VAX-11/780 system. 
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Example 4-3 Running CRASH on a VAX-11/780 System 


I CTRL/P | 

»>HALT 

»><BCRASH 


! Command file to crash VMS abnormally 

j 

HALT ! HALT SYSTEM, EXAMINE PC, 

HALTED AT 8000702A 
EXAMINE PSL ! PSL, 


00000000 

EXAMINE/INTERN/NEXT:4 0 ! And all stack pointers 


00000000 

00000001 

00000002 

00000003 

00000004 


DEPOSIT PC=-1 


80001D48 
00000000 
00000000 
00000000 
8009E600 
! Invalidate PC 


DEPOSIT PSL=1F0000 ! Kernel mode, IPL 31 

CONTINUE 


«DE0F> 

«8EXIT> 

**** FATAL BUG CHECK, VERSION =4.4 INVEXCEPTN, Exception while above 
ASTDEL or on interrupt stack 

CURRENT PROCESS = NULL 


REGISTER DUMP 


RO 

= 

000000IF 

R1 

= 

001F0000 

R2 

= 

00000000 

R3 

= 

00000000 

R4 

= 

00000000 

R5 

s 

00000000 

R6 

= 

00000000 

R7 

= 

00000000 

R8 

= 

00000000 

R9 

= 

00000000 

R10= 

00000000 

Rll 


00000000 

AP 

= 

00000000 

FP 

= 

00000000 

SP 

= 

80001D14 

PC 

= 

800038C1 

PSL= 

001F0009 


KERNEL/INTERRUPT STACK 


80001D1C 
80001D20 
80001D24 
80001D28 


00000004 

00000000 

FFFFFFFD 

00000000 


HALT INST EXECUTED 
HALTED AT 800071B3 
»> 


Typing @CRASH invokes the CRASH console program command file on 
the VAX-11/780 system. This procedure instructs the system to examine the 
program counter (PC), the processor status longword (PSL), and the stack 
pointers. Values are deposited in the PC and PSL to cause an exception 
condition that forces a system dump. The fatal bugcheck message is printed 
at the console terminal. Finally, the system halts and prints the contents of 
the program counter. The console system prompt (> > > ) returns. 
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If automatic rebooting is enabled, some systems will automatically reboot, 
instead of halt. However, if it is not enabled, you must bootstrap the system 
manually. 

On VAX-11/782 attached processor systems, there may be a delay of up to 
two minutes before the system responds to the @CRASH command. 


4.1.4 Emergency Shutdown with CRASH on VAX 8600, VAX 8650 
Systems 

The CRASH procedure described in the previous section differs slightly 
for the VAX 8600 series systems. Example 4-4 illustrates the emergency 
shutdown CRASH procedure for a VAX 8600 or VAX 8650 system. 

Example 4-4 Running CRASH on a VAX 8600 or VAX 8650 
System 


1 CTRL/P 1 
»> 0CRASH 
»> SET QUIET OFF 
»> SET ABORT OFF 
»> HALT 

CPU stopped. INVOKED BY CONSOLE (CSM code 11) 
PC 80008B1F 
»> UNJAM 
»> E PSL 

U PSL 00000000 
»> E/I/N: 4 0 

I 00 80000C40 
I 01 00000000 
I 02 00000000 
I 03 00000000 
I 04 00000000 

»> E SP 

G 0E 80000C40 
»> E/VIR/NEXT: 40 <0 

P 04206840 00000000 
P 04206844 00000000 


P 0420693C 00000000 
P 04206940 00000000 
»> D PC FFFFFFFF 
»> D PSL 1F0000 
»> SET ABORT ON 
»> SET QUIET ON 

**** FATAL BUG CHECK. VERSION = X4.4 INVEXCEPTN, 
Exception while above ASTDEL or on interrupt stack 

CURRENT PROCESS NULL 

REGISTER DUMP 
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4.1.5 Emergency Shutdown with CRASH on VAX—11 /750 Systems 

The console program command file CRASH is not included in the VAX/VMS 
distribution kit for a VAX-11/750 system. If it becomes necessary to perform 
an emergency crash of a VAX-11/750 system, you can enter the equivalent 
instructions manually, as shown in Example 4-5. 

Example 4-5 Running CRASH on a VAX-11/750 System 


| CTRL/P 1 
80007B06 02 

»>E/G F 

G 0000000F 80007B06 

»>E P 


00000000 
»>E/I 0 


I 

»>E/I 1 

00000000 

800009D0 

I 

»>E/I 2 

00000001 

00000000 

I 

>»E/I 3 

00000002 

00000000 

I 

»>E/I 4 

00000003 

00000000 

I 

00000004 

8013C000 


>»D/G F FFFFFFFF 
»>D P 1F0000 
»»C 

**** FATAL BUG CHECK. VERSION =4.4 INVEXCEPTN. Exception while 
above ASTDEL or on interrrupt stack 

CURRENT PROCESS = NULL 
REGISTER DUMP 


HALT INST EXECUTED 
HALTED AT 800076B2 
»> 


The commands instruct the system to examine the program counter (PC), the 
processor status longword (PSL), and the stack pointers. Values are deposited 
in the PC and PSL to cause an exception condition that forces a system 
dump. The fatal bugcheck message is printed at the console terminal, as are 
additional messages and information. (See Example 4-3 for the 
VAX-11/780.) The system dump file is written to the disk. Later, the dump 
file can be used to determine why the system did not respond to command 
input. However, data may be lost, since no other housekeeping functions are 
performed. Finally, the system halts and prints the contents of the program 
counter. The console system prompt (> > > ) returns. 


4.2 Bootstrapping the System 

You can bootstrap the system using either a default or an alternate bootstrap 
command procedure. In both cases, you must bootstrap the system directly 
from the system disk. If you are bootstrapping a VAX-11/750, you can 
use the standalone BOOT58 program on the console TU58 cartridge. This 
procedure is described in Appendix A. 
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Normally you bootstrap using the procedure you have selected as the 
default for your site (see Section 2.4). However, if the default procedure 
is unavailable, or if you are bootstrapping to create an environment for a 
specialized task (such as standalone debugging), you can select an alternate 
procedure. The next sections describe default and alternate bootstrap 
operations. 

Note: In the following sections the bootstrap file type CMD is used. On the 
VAX 8600 series processors the file type is COM. 


4.2.1 Default Bootstrap 

The most direct way to bootstrap your operating system is to activate the 

BOOT switch or to enter console mode and type the BOOT command (or 

simply B). For example: 

»> B 

In either case, the console program looks for your default bootstrap command 

procedure (DEFBOO.CMD) and executes it. 

To bootstrap using the default, proceed as follows: 

1 Halt the system. You halt a VAX-11/730 system by pressing CTRL/P. To 
halt all other VAX processors, press CTRL/P to obtain the console prompt 
(> > > ), and then type HALT. 

2 Either type BOOT or activate the BOOT switch on the processor control 
panel. On most VAX processors, the default bootstrap command 
procedure DEFBOO.CMD is used to bootstrap the system. For 
VAX-11/750 systems, the processor will attempt to bootstrap from the 
device selected by the BOOT DEVICE switch on the front panel. If 
the switch is set to position A, the BOOT58 program is invoked (see 
Appendix A.) 


4.2.2 Alternate Nonstop Bootstrap 

You normally use an alternate nonstop bootstrap command procedure when 
the default procedure cannot be accessed because of problems with the 
device designated in the default procedure. To bootstrap the system using an 
alternate nonstop procedure, follow these steps: 

1 Halt the processor. You halt a VAX-11/730 system by pressing CTRL/P. 
To halt all other VAX processors, press CTRL/P to obtain the console 
prompt (> > > ), and then type HALT. 

2 Bootstrap the system, using the command for your particular processor: 

• For the VAX-11/750 

»> B ddcu 

The code dd is the device type, c is the controller designator, and u is 
the unit number. 

• For all other VAX processors 

»> B ddu 
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The code dd is the device type, and u is the unit number. Refer to 
the specific processor installation guide for more information on the 
specific conversational bootstrap procedure. 


4.2.3 Alternate Conversational Bootstrap 

A conversational bootstrap is most commonly used in research and 
development environments to alter operating conditions for experimentation, 
testing, and debugging. This procedure allows the sophisticated user to 

• Select an alternate file as the source of system parameter values 

• Set and show individual parameter values 

• Specify an alternate site-independent startup procedure 

• Specify a minimum startup 

To initiate a conversational bootstrap, proceed as follows: 

1 Halt the processor. You halt a VAX-11/730 system by pressing CTRL/P. 
To halt all other VAX processors, press CTRL/P to obtain the console 
prompt (> > > ), and then type the HALT command. 

2 Bootstrap the system, using the command for your particular processor: 

• For the VAX-11/750 

»> B/l ddcu 

The code dd is the device type, c is the controller designator, and u is 
the unit number. 

• For all other VAX processors 

»> (SdduGEN 

The code dd is the device type, and u is the unit number. 

3 When SYSBOOT is ready to accept commands, it prompts as follows: 

7.7. 

SYSBOOT> 

On VAX-11/750 systems, the two percent signs that appear above the 
SYSBOOT> prompt indicate a successful verification of the microcode. If 
the percent signs do not appear, discontinue the bootstrap operation and 
contact your field service representative. 

When SYSBOOT prompts, you may use any of the subset of SYSGEN 
commands listed in Table 4-1 to examine or modify the system. You can 
find more information about these commands in the VAX/VMS System 
Generation Utility Reference Manual. 
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Table 4-1 SYSGEN Commands Used in SYSBOOT 


Command 

Description 

CONTINUE 

Resumes the bootstrap procedure 

DISABLE CHECKS 

Inhibits checking of parameter values 
specified with the SET command 

ENABLE CHECKS 

Permits checking of parameter values 
specified with the SET command 

HELP 

Displays a summary of the SYSBOOT 
commands at your terminal 

SET parameter-name 

Establishes the value of a system generation 
parameter 

SET/STARTUP 

Sets the name of the system startup 
command procedure 

SHOW [parameter] 

Displays active, current, default, maximum, 
and minimum values for specific parameters; 
displays, with appropriate qualifiers, 
characteristics of parameters grouped by 
categories 

USE [file-spec] 

Optionally specifies a parameter file to be 
used as a source of values (you must enter 
the entire file specification, including device 
and directory) 


During a typical conversational bootstrap, you might enter the following 
commands to set a new value for the SYSGEN parameter WSMAX and 
continue the procedure: 

SYSB00T> SET WSMAX 512 
SYSBOOT> CONTINUE 

In this example, you set WSMAX to 512, and the bootstrap operation 
continues. When the VAX/VMS system announces itself, the new parameter 
value becomes active. 

You can also use the conversational bootstrap operation to specify a minimum 
startup. For example, if you want to bootstrap your system and avoid 
autoconfiguring all your devices, issue the following command at the 
SYSBOOT> prompt: 

SYSBOOT> SET STARTUP.Pl "MIN" 

This command initiates a minimum startup that performs the following 
sequence of operations: 

1 Starts the processes that control error logging, the job controller, and the 
operator's log 

2 Installs known images 

3 Defines the number of interactive users as eight 

4 Logs off 
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If you want verification set during the execution of a startup procedure, you 
can specify the following command: 

SYSB00T> SET STARTUP_P2 "YES" 

The STARTUP—Pn parameters are not reset for the next bootstrap operation. 


4.2.4 Bootstrapping an HSC Disk 

The manner in which you bootstrap an HSC disk is in part dependent 
on the type of VAX processor you are using. If you have a VAX-11/750, 
you use the BOOT58 utility to bootstrap HSC disks (see Appendix A); for 
other processors, use console mode commands. See the processor-specific 
installation guides for more information. 

In either case, you must alter an appropriate bootstrap command file on your 
console volume: CIBOO.CMD if you want to use a nonstop boot, or CIGEN. 
if you want to use a conversational boot. If you are installing a new system, 
that is, not upgrading your current system, you must use CIBOO.CMD. 

The Cl bootstrap command procedures let you bootstrap from an HSC 
disk, but first you must add two pieces of information to the file: the unit 
number of the disk drive, and the node number of the HSC controlling 
it. Furthermore, if you want to bootstrap from a system root other than 
[SYSO], you must identify the root. Note, however, that when installing a 
system, you bootstrap from [SYSO]. See Section 2.8.2.2 for more information 
on bootstrapping from alternate system roots; see the Guide to VAX/VMS 
Software Installation for details on creating alternate roots. 

There are two ways to provide the information needed by the Cl bootstrap 
command procedures, depending on whether you have a running system or 
whether you are installing a new system. 

If you have a running system, you can copy the Cl bootstrap command file 
from the console volume to a disk directory, edit it, and then copy the edited 
version back to the console volume. If you want to use the Cl bootstrap 
command file as your default bootstrap command procedure, copy the edited 
version to DEFBOO.CMD on the console volume. 

If you are installing a new system, you will have to use console commands 
(BOOT58 commands if you have a VAX-11/750) to deposit the information 
needed by the Cl bootstrap command files before bootstrapping your HSC 
device. Note that the form of the DEPOSIT command varies for different 
VAX processors. 

The following sections describe the bootstrapping of HSC disks in four 
enviroments: 

• On a VAX-11/780 (and similar processors) during an installation 

• On a running VAX-11/780 (and similar processors) 

• On a VAX-11/750 during an installation 

• On a running VAX-11/750 
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4.2.4.1 Bootstrapping an HSC Disk on a VAX—11/780 During an Installation 

The following procedure assumes that you are bootstrapping an HSC disk on 
a VAX-11/780 while you are installing a new operating system. 

1 Determine the unit number of the HSC disk and the node number of the 
HSC controlling it. 

2 Press CTRL/P to put the system in console mode. 

3 Use the console HALT command to stop the processor. 

4 When the console prompt (> > > ) appears, deposit the HSC node 
number into register R2 using the following command format: 

»> DEPOSIT R2 node_number 

Note that all numeric entries are made using hexadecimal notation. For 
example, if the HSC is node number 12 on the CI780, you use this 
command: 

»> DEPOSIT R2 OC 

5 If the disk device is accessible to two HSCs, deposit both node numbers 
putting the greater number in hexadecimal digits 3 and 2, and the lesser in 
digits 1 and 0. For example, if one HSC is numbered 14 (hex OE) and the 
other is numbered 10 (hex 0A), the proper command is 

»> DEPOSIT R2 OEOA 

6 Deposit the unit number of the HSC disk into register R3 using the 
following command format: 

»> DEPOSIT R3 unit_number 

For example, if the HSC disk is unit number 21, deposit a hex 15 into R3: 

»> DEPOSIT R3 15 

7 Bootstrap the HSC disk with this command: 

»> (8CIB00.CMD 

(See Appendix A for more information on the BOOT58 program.) 


4.2.4.2 Bootstrapping an HSC Disk on a Running VAX-11/780 

The following procedure shows how to set up DEFBOO.CMD to do a nonstop 
system bootstrap of an HSC disk on a VAX-11/780 system that is up and 
running. For purposes of illustration, the HSC device is assumed to be an 
RA60 disk drive assigned unit number 03 on an HSC controller assigned node 
number 0C. The procedure assumes that you want to bootstrap the system 
from alternate root SYS A. 

1 Be sure your console drive is connected. If it is not, invoke the System 
Generation Utility (SYSGEN) to connect it, as follows: 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT CONSOLE 

2 Exit from SYSGEN: 

SYSGEN> EXIT 

3 Mount the console volume: 

$ MOUNT/FOREIGN CSA1: 
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4 Copy CIBOO.CMD to your default disk directory with this command: 

$ EXCHANGE COPY CSA1:CIBOO.CMD *.* 

5 Edit the disk file in your default directory as shown in the following 
example. The first line you add deposits the HSC node number in R2, and 
the second line you add deposits the HSC disk's unit number in R3. 

To set the system root at [SYSA], you edit the line commented as 
DESIGNATED ROOT IS SYSA by changing the most significant digit 
in R5 to the letter A. This digit determines the system root for system 
disks with multiple systems. 

Note that all numeric entries are made using hexadecimal notation. 


DEPOSIT RO 20 
DEPOSIT R1 F3E000 
DEPOSIT R2 OC 
DEPOSIT R3 03 
DEPOSIT R4 0 
DEPOSIT R5 A0004000 


!CI PORT DEVICE 
!Cl TR=E 

!HSC NODE NUMBER 
!DEVICE UNIT NUMBER 
IBOOT BLOCK LBN (NOT USED) 
!DESIGNATED ROOT IS SYSA 


6 If the disk is dual-ported (accessible to two HSC controllers), you must 
specify the node number of both controllers in register R2. Further, you 
must specify the higher-numbered node in bits < 15:8> and the lower- 
numbered node in bits <7:0>. For example, if the disk is accessible to 
the HSC numbered OC and the HSC numbered OA, the line for R2 should 
appear like this: 

DEPOSIT R2 OCOA !DUAL-PORTED HSC NODE NUMBERS 

7 Copy the edited bootstrap command file to the default bootstrap command 
procedure (DEFBOO.CMD) on your console volume with this command: 

$ EXCHANGE COPY CIBOO.CMD CSA1:DEFBOO.CMD 

You should provide a spare copy of this file in case DEFBOO.CMD is 
overwritten. Use the same command, but provide a distinctive file name 
for the spare file. 

8 Shut down the system with this command: 

$ @SYS$SYSTEM:SHUTDOWN 

9 Press CTRL/P to put the system into console mode. 

10 Use the HALT command to stop the processor. 

11 Bootstrap the HSC disk by invoking the default bootstrap command 
procedure: 

»> B 
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4.2.4.3 Bootstrapping an HSC Disk on a VAX—11/750 During Installation 

The following procedure shows how to bootstrap an HSC disk on a 

VAX-11/750 while installing a new operating system. 

1 At the processor control panel, set the BOOT SELECT switch to 
position A. 

2 Determine the unit number of the HSC disk and the node number of the 
HSC controlling it. 

3 Press CTRL/P to put the system in console mode. 

4 When the console prompt (> > > ) appears, invoke BOOT58 with this 
command: 

»> B/800 DDAO 

Note: If you fail to add the /800 qualifier, the console program will try to 
execute DEFBOO.CMD. 

5 When the BOOT58> prompt appears, deposit the HSC node number into 
register R2 using the following command format: 

B00T58> D/G 2 node_number 

Note that all numeric entries are made using hexadecimal notation. For 
example, if the HSC is node number 12 on the CI750, you use this 
command: 

B00T58> D/G 2 OC 

6 If the load device is accessible to two HSCs, deposit both node numbers, 
putting the greater number in hexadecimal digits 3 and 2, and the lesser in 
digits 1 and 0. For example, if one HSC is numbered 14 (hex OE) and the 
other is numbered 10 (hex 0A), the proper command is 

B00T58> D/G 2 0E0A 

7 Deposit the unit number of the load device into register R3 using the 
following command format: 

B00T58> D/G 3 unit_number 

For example, if the load device is unit number 21, deposit hex 15 into R3: 

B00T58> D/G 3 15 

8 Bootstrap the HSC disk with this command: 

B00T58> (8CIB00.CMD 


4.2.4.4 Bootstrapping an HSC Disk on a Running VAX-11/750 

This section describes how to set up DEFBOO.CMD to do a nonstop system 
bootstrap of an HSC disk on a VAX-11/750 system that is up and running. 
For purposes of illustration, the HSC device is assumed to be an RA60 disk 
drive assigned unit number 03 on an HSC controller assigned node number 
12 (hexadecimal 0C). It is further assumed that the user wants to bootstrap 
the system from alternate root SYSA. 

1 Set the BOOT SELECT switch to position A. 

2 Be sure your console drive is connected. If it is not, invoke the System 
Generation Utility (SYSGEN) to connect it, as follows: 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT CONSOLE 
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3 Exit from SYSGEN: 

SYSGEN> EXIT 

4 Mount the console volume: 

$ MOUNT/FOREIGN CSA1: 

5 Use the Exchange Utility (EXCHANGE) to copy CIBOO.CMD to your 
default disk directory. 

$ EXCHANGE COPY CSAliCIB00.CMD *.* 

6 Edit the disk file in your default directory and add the two lines 
commented as "HSC NODE NUMBER" and "DEVICE UNIT NUMBER". 
The first line deposits the HSC node number in register R2, and the 
second line deposits the HSC disk's unit number in register R3. 

To set the system root at SYSA, you edit the line commented as 
SOFTWARE BOOT CONTROL FLAGS by changing the most significant 
digit in register R5 to the letter A. This digit determines the system root 
for system disks with multiple systems. 

Note that all numeric entries are made using hexadecimal notation. 


D/G 0 

20 

!Cl PORT DEVICE 

D/G 1 

F3E000 

!Cl TR=E 

D/G 2 

OC 

!HSC NODE NUMBER 

D/G 3 

03 

!DEVICE UNIT NUMBER 

D/G 4 

0 

!BOOT BLOCK LBN (NOT USED) 

D/G 5 

A0004000 

•SOFTWARE BOOT CONTROL FLAGS 


7 If the disk is dual-ported (accessible to two HSC controllers), you must 
specify the node numbers of both controllers in register R2. Further, you 
must specify the higher-numbered node in bits < 15:8> and the lower- 
numbered node in bits <7:0>. For example, if the disk is accessible 

to the HSC numbered 12 (hexadecimal OC) and the HSC numbered 10 
(hexadecimal 0A), the line for register R2 should appear like this: 

D/G R2 OCOA !DUAL-PORTED HSC NODE NUMBERS 

8 Copy the edited boot command to the default boot command procedure 
(DEFBOO.CMD) on your console volume. 

$ EXCHANGE COPY CIBOO.CMD CSA1:DEFB00.CMD 

You should provide another copy of this file in case DEFBOO.CMD is 
overwritten. Use the same command, but provide a distinctive file name 
for the other file. 

9 Write the boot block on the TU58 cartridge using the Writeboot Utility, 
a Invoke WRITEBOOT: 

$ RUN SYS$SYSTEM:WRITEBOOT 

b When WRITEBOOT asks for the target device, make the following 
entry: 

Target system device (and boot file if not VMB.EXE):? CSAi:B00T58.EXE 

c In response to the following question, enter the number 1: 

Enter VBN of boot file code (default is one): 1 
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d When you are asked for the address of the primary bootstrap, enter 
C000: 

Enter load address of primary bootstrap in HEX (default is 200): C000 

I 0 Shut down the system: 

$ <0SYS$SYSTEM: SHUTDOWN 

II Press CTRL/P to put the system in console mode: 

12 When the console prompt appears (> > > ), bootstrap the HSC disk: 

»> B 


4.2.5 Bootstrapping a VAX—11 /780 with Interleaved Memory 

To bootstrap a VAX-11/780 system with interleaved memory, you must 
verify that the system conforms to certain requirements, as described in the 
VAX Hardware Handbook. If your system meets these requirements, edit 
the default bootstrap command procedure (DEFBOO.CMD) and the powerfail 
restart command procedure (RESTAR.CMD) to include commands that modify 
the memory controller registers. 

DEFBOO.CMD and RESTAR.CMD are on the console floppy diskette. Copy 
the files from the console floppy diskette, edit them, and return them to 
the floppy diskette using the DXCOPY command procedure described in 
Section 2.5. 


4.3 Restarting Problems 

Sometimes the operating system does not bootstrap after you have issued 
the BOOT command. This can be caused by either a hardware or software 
malfunction. 


4.3.1 Hardware Problems 

A read error on a disk drive or console medium, or a machine check error, 
may indicate a hardware malfunction. When a hardware problem occurs, a 
question mark (?) usually precedes the error message that is displayed on the 
system console terminal. You should then 

1 Consult the appropriate hardware manual for your VAX processor. 

2 Contact the appropriate DIGITAL Field Service representative. 
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4.3.2 Software Problems 

When the operating system is loaded into memory but the STARTUP.COM 
command procedure does not execute, a software malfunction has probably 
occurred. You should suspect this condition if the usual message specifying 
the number of interactive users does not appear. 

You can perform one or both of the following actions to correct the situation: 

• Try again, by repeating the bootstrap procedure to restart (see the software 
installation booklet for your VAX processor). 

• Leave the system disk in the original drive. Place a backup copy in 
another drive, swap unit plugs in the two drives, and try again. 
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Effective system management depends to a large degree on effective user 
management. The control of system functions on a user-by-user basis plays a 
vital role in managing system resources and thus enhancing system efficiency 
and security. 

In order to manage users effectively, you must understand 

• Who needs access to the system 

• What tasks they must perform 

• What system resources they will require 

• What information you should provide them 

Once you understand user needs, you can establish controls that will tailor 
the system appropriately. VAX/VMS provides several tools to authorize 
and control the use of system resources by individual users. This chapter 
describes these tools and discusses how and when to use them. 


5.1 User Authorization File 

You manage VAX/VMS users primarily by creating and maintaining user 
accounts, which control who may log in to the system and how individuals 
may use it. 

User accounts are defined by records in a file (SYS$SYSTEM:SYSUAF.DAT) 
called the user authorization file (UAF), which you maintain using the 
Authorize Utility (AUTHORIZE). A detailed explanation of how to use 
AUTHORIZE is presented in the VAX/VMS Authorize Utility Reference Manual. 

Whenever a user logs in, the system uses the information contained in the 
UAF to validate the login attempt, establish the account's environment, and 
create a process with appropriate attributes. In this way, the system restricts 
users to the resources you assign to each account. 

The procedures for adding a user account are discussed in detail later in 
this chapter. Since, however, the UAF is the prime repository for storing 
information about user accounts, it is important to understand its components 
before you add accounts. 

Using the Authorize Utility, you create and maintain UAF records by 
assigning values to various fields within each record. The values you assign 
identify the user, define the user's work environment, and control use of 
system resources. Example 5-1 presents a typical UAF record for a restricted 
user account and describes its fields. To gain access to a specific user record, 
you set your default to the SYS$SYSTEM directory, and issue the command 
SHOW user-name. 
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Example 5-1 Sample UAF Record Display 


Username: WELCH 
Account: 

CLI: DCL 

Default: USER3:[WELCH] 

LGICMD: 

Login Flags: Diswelcome Disnewmail 
Primary days: Mon Tue Wed Thu Fri 

Secondary days: 

Primary 000000000011111111112222 
Day Hours 012345678901234567890123 

Network: - No access - 

Batch: XXXXXXXXX-XXXXXXX 

Local: XXXXXXXXX-XXXXXXX 

Full access - 

Full access - 

(none) 


Owner: ROB WELCH O 
UIC: [21,51] ([INV,WELCH]) 

Tables: DCLTABLES © 


Dialup: — 

Remote: — 

Expiration: 
Pwdlifetime: 
Last Login: 


(none) 

(none) 


Sat Sun 

Secondary 000000000011111111112222 
Day Hours 012345678901234567890123 

- Full access - 

-XXXXXXXXX- 

-XXXXXXXXX- 

- -No access- 

- -No access- 

Pwdminimum: 6 Login Fails: 0 

Pwdchange: 15-APR-1984 13:58 

(interactive), (none) (non-interactive) 


Maxjobs: 

0 

Fillm: 

20 

Bytlm: 

8192 

Maxacctjobs: 

0 

Shrfillm: 

0 

Pbytlm: 

0 

Maxdetach: 

0 

BlOlm: 

18 

JTquota: 

1024 

Prclm: 

2 

DIOlm: 

18 

WSdef: 

150 

Prio: 

4 

ASTlm: 

24 

WSquo: 

200 

Queprio: 

4 

TQElm: 

10 

WSextent: 

500 

CPU: 

(none) 

Enqlm: 

30 

Pgflquo: 

10000 


Authorized Privileges: 

TMPMBX NETMBX 
Default Privileges: 
TMPMBX NETMBX 


O User identification fields contain information used by the system for both 
accounting purposes and user identification. 

© Default fields contain the default specifications for 

• The command language interpreter (DCL by default) 

• The name of the command procedure to be executed automatically at 
login time. If the field is blank, SYS$LOGIN:LOGIN.COM is executed 
by default. 

• The command language interpreter tables (if blank, same as CLI) 

• The device and directory names for file access 

© Login characteristics fields impose specific login restrictions that 

• Inhibit certain login functions 

• Control the days of the week when various types of logins are 
permitted 

• Control the times of day when various types of logins are permitted 
© Resource control fields control system resources by 

• Limiting the use of reusable system resources 

• Specifying the base priority used in scheduling the process that the 
system creates for the user 

© Privileges fields specify the privileges that allow use of restricted and 
sensitive system functions. 
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5.1.1 System-Supplied UAF Records 

The software distribution kit provided with a new VAX/VMS system contains 

a UAF of four records: 

• DEFAULT —Serves as a template for creating user records in the UAF. 

A new user record is assigned the values of the DEFAULT record except 
where you explicitly override those values. Thus, whenever you add a 
new account, you need only specify values for fields that you want to be 
different. For example, the following AUTHORIZE command creates a 
new record having the same values as the DEFAULT record, except that 
the password, UIC, and default directory fields are changed. 

UAF> ADD MARCONI/PASSW0RD=QLP6YT9A/UIC=[033,004] - 
_UAF> /DIRECTORY=[MARCONI] 

Section 5.3 gives an example of how to use AUTHORIZE to add a user 
account. 

You can also use AUTHORIZE to modify the DEFAULT record to suit 
your needs or to create additional default record templates for specific 
account types. Section 5.5.1 explains how to create and use additional 
default templates. 

Note: The default record cannot be renamed or deleted from the UAF. 

• FIELD —Permits DIGITAL Field Service personnel to check out a new 
system. The FIELD record can be disabled once the system is installed. 

• SYSTEM —Provides a means for you to log in with full privilege. The 
SYSTEM record can be modified but cannot be renamed or deleted 
from the UAF. Note that if you change the SYSTEM record, particularly 
the default device and directory and the privileges, you could prevent 
successful installation of optional software products or future VAX/VMS 
maintenance releases. 

• SYSTEST —Provides an appropriate environment for running the User 
Environment Test Package (UETP). The SYSTEST record can be disabled 
once the system is installed. 


5.1.2 General Maintenance of the UAF 

Typically, you use the UAF supplied with the distribution kit. (You can, 
however, rename the UAF with the DCL command RENAME, and then 
create a new UAF with AUTHORIZE.) You should limit any kind of access to 
this file to the SYSTEM account (see the Guide to VAX/VMS System Security 
for guidelines on protecting system files). Furthermore, each time you modify 
the file, you should create a backup copy so that in case of a system failure 
you do not lose the modifications. See the VAX/VMS Backup Utility Reference 
Manual for guidelines on backing up files. 

The UAF is accessed as a shared file, and updates to the UAF are made on 
a per-record basis, which eliminates the need for both a temporary UAF 
and a new version of the UAF after each AUTHORIZE session. Updates 
become effective as soon as AUTHORIZE commands are entered, not after 
the termination of AUTHORIZE. (For this reason, you should not enter 
temporary values with the intent of fixing them later in the session.) 
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Immediately after installing the system, you should make the following 
modifications to the UAF: 

• SYSTEM, FIELD, and SYSTEST accounts —Change the passwords 
immediately. Use obscure passwords of six characters or more and 
continue to change them on a regular basis. You should not permit 
general users access to these accounts. 

In addition to changing the password, you can specify 
MODIFY/FLAGS=DISUSER with AUTHORIZE, especially if you use the 
account infrequently. The login flag DISUSER disables the account and 
prevents anyone from logging in on the account. To enable the account 
when it is needed, run AUTHORIZE and specify 
MODIFY/FLAGS=NODISUSER. 

Warning: Be careful not to disable all of your privileged system accounts. If you 
inadvertently do so, you can recover by setting the UAF ALTERNATE 
SYSGEN parameter during an interactive bootstrap operation. See 
Section 5.7 for information on alternate login procedures. 

As a general rule, do not make any other changes in the SYSTEM UAF 
record; installation of VAX/VMS maintenance releases and optional 
software products depends on certain values in this record. 

• DEFAULT account —You may want to change several fields in this 
account. For example: 

UAF> MODIFY DEFAULT/DEVICE=DISK$USER/WSQU0=750 

The default device is set to the name most commonly used for user 
accounts that will be added. Likewise the working set value is set to a 
value appropriate for most users on the system. 

Note that you use the SYSTEM account only for system functions such as 
performing backups and installing maintenance updates. The account comes 
to you with full privileges, so you must exercise caution in using it. For 
example, because you have BYPASS privilege, the system will allow you to 
delete any file no matter what its protection. If you type an incorrect name 
or spurious asterisk, you may destroy files that you or other users need to 
keep. For this reason, you should use another account with fewer privileges 
for day-to-day system management activities. 

If you want to receive mail on the SYSTEM account, you can define a 
systemwide logical name in the site-specific startup command procedure 
(see Section 2) to equate SYSTEM to the user name of the system manager's 
account. You can also use the MAIL command SET FORWARD to have any 
SYSTEM mail forwarded to any other account. 


5.2 Preparing to Add a User Account 

Set the default to the SYS$SYSTEM directory to invoke the Authorize Utility. 

How you set up a user account depends on the needs of the individual user. 

In general, there are two types of accounts: 

• Interactive —A person using an interactive account has access to the 
system software and can perform work of a general nature (program 
development, text editing, and so on). Normally, such an account is 
considered individual; that is, only one person can use it. 
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• Turnkey —A person using a turnkey or captive account has access only 
to user software and can only perform strictly limited work. Normally, 
such an account is considered functional; that is, anyone who needs to 
perform the particular work can use it. As an example, you might develop 
an inventory system. Anyone whose job entails inventory control can 
access your system, but that person cannot access other systems or the 
base software. 

The suggested procedures for preparing to add a user account are as follows: 

1 Determine a user name and password. 

2 Determine a user identification code (UIC). 

3 Decide where the account's files will reside (which device and directory) 

4 Use the Disk Quota Utility (DISKQUOTA) to add a disk quota entry for 
this UIC, if disk quotas are in effect. 

5 Create a first-level directory on the appropriate volume. 

6 Establish any login/logout command files. 

When you have completed these steps, you can invoke the Authorize Utility 
as described in Section 5.3 and add the account. 

The sections that follow discuss each step in the creation of a user account 
and introduce the various management utilities and commands used. Detailed 
descriptions of the utilities and commands appear in the individual VAX/VMS 
utility reference manuals and in the VAX/VMS DCL Dictionary. 


5.2.1 User Name and Password 

To determine a user name and password, use naming conventions that take 
into consideration the nature of the account. For example, interactive accounts 
are usually named after the person using the account. Turnkey accounts, on 
the other hand, use a name that describes the function of the account. Thus, 
an interactive account for Robert Jones would typically have a user name of 
JONES, while a turnkey account for an inventory system would typically be 
called INVENTORY. On systems with a large number of users, you should 
remember to assign user names that are unique. 

For interactive accounts, it is best to let the person using the account control 
the password. Initially, you provide a simple password and tell the user to 
change the password with the DCL command SET PASSWORD. Only the 
person using the account need know the password. You should encourage all 
users to set obscure passwords of at least six characters and to change them 
frequently. 

To provide additional protection to a user account, a secondary password can 
be added. The initial setting of the secondary password is controlled by the 
system manager using the Authorize Utility. See the VAX/VMS Authorize 
Utility Reference Manual for information on adding and modifying secondary 
passwords. 

For turnkey accounts, the degree of sensitivity of the data used by the account 
should determine the type of password. For example, the password for a 
payroll application should be obscure, while the password for a suggestions 
account might not even be required; it could be null (in which case users 
would not be prompted for the password). 
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You should prohibit users from changing the passwords of turnkey accounts, 
To do this, specify /FLAGS=LOCKPWD when you add the account with 
the Authorize Utility. Change the password whenever you feel it might be 
compromised (for example, if a person using the account moves to another 
job). You change a user's password by issuing the command 
MODIFY/user-name/PASSWORD. 


5.2.2 User Identification Code 

See the VAX/VMS DCL Concepts Manual for a detailed discussion of the UIC. 
In general, you assign each account a unique UIC, and you should assign 
accounts the same group number if they perform similar work, access the 
same files frequently, and/or use many of the same logical names. 


5.2.3 Disk Quota Entry 

If disk quotas are in effect for the volume, run the Disk Quota Utility 
(DISKQUOTA) to add an entry for the new UIC. Disk quotas limit the 
amount of disk space available to individual users on a particular volume. 

To add a disk quota entry, run DISKQUOTA as follows: 

$ RUN SYStSYSTEM:DISKQUOTA 
DISKQ> USE DISKIUSER 

DISKQ> ADD [014,006] /PERMQU0TA=2OOO/0VERDRAFT=5OO 
DISKQ> EXIT 

The commands in this example 

• Invoke DISKQUOTA 

• Specify the disk DISK$USER as the volume on which quotas are set 

• Add a disk quota entry of 2000 blocks for UIC [014,006] and assign the 
entry an overdraft of 500 blocks 

• Exit from the utility 

The sum of the quota and overdraft values is the absolute maximum number 
of blocks allotted to the user, which in this example is 2500 blocks. A 
discussion of disk quotas is presented in Section 7.8.2.1. The Disk Quota 
Utility is described in detail in the VAX/VMS Disk Quota Utility Reference 
Manual. 


5.2.4 User Directory and Default File Specification 

For each interactive account, you should create a first-level directory (using 
the DCL command CREATE/DIRECTORY) under which the interactive user 
can create and maintain files and subdirectories. Make the owner of the 
directory the UIC you have decided upon for the new account. Typically, you 
also use the name of the account for the first-level directory. For example, if 
you have decided upon an account name of JONES and a UIC of [014,006], 
you would issue the following DCL command to create a first-level directory 
for the account on the volume DISK$USER: 

$ CREATE/DIRECTORY DISK$USER:[JONES]/0WNER_UIC=[014,006] 

The volume on which the directory is established depends on which devices 
you reserve for interactive accounts and how much space is available on each. 
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The default file specification you provide the new account (when you run 
AUTHORIZE) should be the name of the device and the name of the first- 
level directory you used in the DCL command CREATE/DIRECTORY. 

For a turnkey account, whether you create a first-level directory depends 
on the nature of the user system. Where the user system uses files 
in a particular directory, you should make that directory the default 
directory specification. For example, if the inventory system uses the files 
DISK$DATA:[INV]STOCKl.DAT and DISK$DATA:[INV]STOCK2.DAT, the 
default device specification should be DISK$DATA: and the default directory 
specification should be [INV]. 


5.2.5 Login Command Procedures for Interactive Accounts 

For interactive accounts, login command procedures contain commands 
commonly executed at the beginning of every user session. These commands 
do such things as 

• Define symbols 

• Assign logical names 

• Display messages and the time of day 

• Set terminal characteristics 

• Define keys to perform certain functions 

Login command procedures are useful for both saving keystrokes and 
standardizing operations. In establishing login command procedures for 
interactive accounts, you have the following choices: 

• System —As system manager, you normally create and maintain a 
standard login command procedure in the system directory (the file is 
typically named SYS$MANAGER:SYLOGIN.COM). You then equate the 
logical name SYS$SYLOGIN to the name of the file so that whenever a 
user logs in, the procedure is executed. 

• Individual —For any or all accounts, you may specify an additional 
login command procedure with the /LGICMD qualifier of AUTHORIZE. 
You can give the login command file any valid file specification. Then, 
whenever the user logs in, the specified procedure is executed after 
SYS$SYLOGIN. 

• User-specified command file —If individual or system login command 
procedures are not implemented, the system looks for a command file 
called LOGIN in the user's login directory (as defined by the SYS$LOGIN 
logical name). If the file is found, the system executes it. This command 
file is developed and maintained by the user and should follow these 
conventions: 

— Device and directory names must take the default file specification for 
the account. 

— The file name must be LOGIN. 

As an aid to new users, you might copy a login command procedure 
template into newly created first-level directories. However, to ensure 
proper ownership of the file, you must change the owner UIC of the file 
to that of the user. You make this change with the DCL command SET 
FILE/OWNER _UIC. 
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Examples 5-2 and 5-3 illustrate typical system and user-specified login 
command procedures. 

Example 5-2 Sample SYS$MANAGER:SYLOGIN.COM Login 
Command Procedure 


$ V = F$VERIFY(0) 

ISTART: 

$ ! 

$ SET N0C0NTR0L=Y ! Do not allow CTRL/Y to exit procedure 

$ SET NOON 

$ • 

$ ! Set default file protection back to the old default 

$ ! 

$ SET PROTECTIONSSY:RWED.OW:RWED,GR:RWED,WO:RE)/DEFAULT 

$ ! 

$ ! Allow network jobs to start faster 

$ ! 

$ IF F$M0DE() .EQS. "NETWORK" THEN GOTO EXIT 

$ ! 

$ ! Enable CTRL/T handling by DCL 

$ • 

$ SET C0NTR0L=T 

$ ! 

$ ! Define Foreign Commands For Installed Utilities 

$ ! 


$ 

SDA 

== 

"ANALYZE/CRASH.DUMP" 

$ 

USERS 

== 

"SHOW USERS" 

$ 

DISPLAY 

== 

"MONITOR PROCESSES/TOPCPU 1 

$ 

NCP 

== 

»$NCP" 

$ 

INFO 

== 

"SHOW PROCESS/CONTINUOUS" 

$ 

SUSPEND 

== 

"SET PROCESS/SUSPEND" 

$ 

RESUME 

== 

"SET PROCESS/RESUME" 

$ 

SETNAME 

== 

"SET PROCESS/NAME" 


$ ! 

$ ! Define a symbol indicating whether the terminal 

$ ! is on a dialup port 

$ ! 

$ TT == F$GETDVI("TT","DEVNAM") 

$ DIALUP == ((TT .GES. "TTGO:" .AND. TT .LES. "TTG4:") - 
.OR. (TT .GES. "TTH1:" .AND. TT .LES. "TTH4:") - 
.OR. (TT .EQS. "TTI5:")) 

$ IF DIALUP THEN SET TERMINAL/INQUIRE 

$ ! 

$EXIT: 

$ IF V THEN SET VERIFY 


$ SET C0NTR0L=Y 
$ EXIT 


As Example 5-2 shows, you can disable the CTRL/Y function (which 
suspends execution of the current image and invokes the command 
interpreter) to force execution of the complete login command procedure 
whenever the user logs in. You can do this with the DCL command SET 
NOCONTROL=Y. The login command procedure should, at some point, reset 
the CTRL/Y function with the DCL command SET CONTROL=Y. 
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Example 5-3 Sample LOGIN.COM Login Command Procedure 


$ SET NOON 

$ SET PROTECT10N=(S=RD,0=RWED,G=R,W=R)/DEFAULT 

$ ! 

$ ! Define abbreviations for often used commands 

$ ! 

$ DIRECTORY == DIRECTORY/DATE/SIZE 

$ PH*ONE == PHONE/SCROLL 

$ > 

$ ! 

$ ! Other useful abbreviations 

$ ! 


$ SHP 

== 

"SHOW PROCESS/PRIVILEGES" 

$ PRI*NT 

ss 

"PRINT/NOTIFY" 

$ SHD 

== 

"SHOW DEFAULT" 

$ UP 

== 

"SET DEFAULT [-]" 

$ SP 

ss 

"SET PROCESS/PRIVILEGES=" 

$ sq 

== 

"SHOW QUEUE/BATCH/ALL/DEVICE" 

$ H*OME 

== 

"SET DEFAULT SYSlLOGIN" 

$ SUB*MIT 

== 

"SUBMIT/NOTIFY" 

$ SPC 

ss 

"SHOW PROCESS/CONTINUOUS" 

$ SYS 

== 

"SHOW SYSTEM" 

$ DAY 

* i 

== 

"SHOW TIME" 

* 

$ ! Set /LOG for all 
* 1 

commands 

♦ : 

$ BACK*UP 

-= 

"BACKUP/LOG" 

$ DEL*ETE 

== 

"DELETE/LOG" 

$ LIB*RARY 

ss 

"LIBRARY/LOG" 

$ PUR*GE 

== 

"PURGE/LOG" 

$ REN*AME 

ss 

"RENAME/LOG" 

$ ! End of LOGIN 

* i 

(.COM 

processing 

$ GOTO 'F$MODE() 


$NETWORK: 



$ EXIT 



$INTERACTIVE: 



$ VN 

== 

"SET TERMINAL/WIDTH=80" 

$ VW 

== 

"SET TERMINAL/WIDTH=132" 

$ EXPERT 

ss 

"SET MESSAGE/NOFACIL/NOSEVER/NOIDENT" 

$ NOVICE 

== 

"SET MESSAGE/FACILITY/SEVERITY/IDENTIF' 


$ NOVICE 

$ ! 


$ ! Symbols for 
± i 

network users 




♦ 

$ SYSA 

== "SET 

HOST 

SYSA" 



$ SYSB 

== "SET 

HOST 

SYSB" 



$ SYSC 

== "SET 

HOST 

SYSC" 



$ EXIT 
$BATCH: 



! End 

of 

interactive login 

$ SET VERIFY 
$ EXIT 



! End 

of 

batch login 
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5.2.6 Login Command Procedures for Turnkey Accounts 

For turnkey accounts, the login command procedure specified by the 
/LGICMD qualifier of AUTHORIZE directs the account user into an 
application program and logs the user out upon termination of the task. 

The login command procedure for the inventory system, for example, might 
consist of the following commands: 

$ DEFINE SYS$DISK DISK$INVENT 
$ RUN INVENTORY 
$ LOGOUT 

The application program INVENTORY assumes control transparently to 
the person logging into the account. You should assign the CAPTIVE 
flag to the login flags field of the turnkey account record by specifying 
the AUTHORIZE qualifier /FLAGSCAPTIVE. The CAPTIVE flag locks the 
user of the turnkey account into the application software. Section 5.3 shows 
how to use AUTHORIZE to create a UAF record for a turnkey account. 


5.2.7 Logout Command Procedures 

The system does not provide for automatic execution of a command procedure 
at logout time. However, you can supply one as follows: 

1 Create a systemwide logout command procedure that executes 
whenever a user logs out (the file is typically named 
SYS$MANAGER:SYLOGOUT.COM). 

2 To ensure that this command procedure always executes, include a 
command in SYS$MANAGER:SYLOGIN.COM that equates the most 
commonly used abbreviation of the LOGOUT command (often LO) to the 
execution of the logout command procedure. For example: 

$ LO*GOUT: ==<8SYS$MANAGER: SYLOGOUT 

The last line of the logout command procedure then uses an alternate form 
of the LOGOUT command, such as a LOGOUTNOW command. (You can 
create any command name you like beginning with LO.) You cannot use 
the same abbreviation as used for the symbol (in this case LO) because it 
will start the procedure again. As an alternative, you could make the next 
to the last line of the procedure: 

$ DELETE/SYMBOL/GLOBAL LOGOUT 


5.3 Using AUTHORIZE to Add a User Account 

Once you have analyzed the purpose of a user account and decided which 
attributes and resources it requires, you can use the Authorize Utility to 
create it. 

Give yourself the SYSPRV privilege. Then issue the following commands to 
set your default device and directory to that of SYS$SYSTEM and invoke the 
utility: 

$ SET DEFAULT SYS$SYSTEM 

$ RUN AUTHORIZE 

UAF> 
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When the utility responds with the UAF> prompt, you can add a typical 
interactive account as follows: 

UAF> ADD J0NES/PASSW0RD=LPB57WM/UIC=[014,006] - 
_UAF> /DEVICE=DISK$USER/DIRECTORY=[JONES] - 
_UAF> /LGICMD=DISK$USER:[NEWPROD]GRPLOGIN - 
_UAF> /0WNER="R0BERT JONES n /ACCOUNT=NEWPROD 

The /OWNER and /ACCOUNT specifications are primarily for accounting 
purposes and can be omitted. The following unspecified qualifiers typically 
take their default values from the DEFAULT record: 

• Limits and Quotas (/ASTLM, /BIOLM, /CPUTIME, /DIOLM, /ENQLM, 
/FILLM, /JTQUOTA, /MAXACCTJOBS, /MAXDETACH, /MAXJOBS, 
/PGFLQUOTA, /PRCLM, /SHRFILLM, /TQELM, /WSDEFAULT, 
/WSEXTENT, /WSQUOTA)—These qualifiers impose limits on the use 
of reusable system resources. See Section 6 for a discussion of limits and 
quotas; the defaults are normally adequate. 

• Priority (/PRIORITY, /QUEPRIORITY)—The default values are normally 
adequate for accounts not running real-time processes. See Section 6 for a 
discussion of the processor priorities. 

• Privileges (/DEFPRIVILEGES, /PRIVILEGES)—See Section 6 for a 
discussion of privileges; the default privileges (TMPMBX, NETMBX) are 
normally adequate. 

• Primary and Secondary Login Times; Login Functions (/ACCESS, 
/DIALUP, /FLAGS, /INTERACTIVE, /LOCAL, /PRIMEDAYS, 
/REMOTE)—By default, users are allowed to log in at any hour of 

any day. To override the setting of a particular day, you can use the DCL 
command SET DAY. Use this command if a holiday occurs on a day that 
would normally be treated as a primary day and you want it treated as a 
secondary day. See Section 5.5.5 for a discussion of using these fields to 
restrict login times and functions. 

• Command Language Interpreter (DCL) —Specify MCR if running in RSX 
compatibility mode. 

The following example shows an AUTHORIZE command that adds the record 
for a turnkey account: 

UAF> ADD INVENT0RY/PASSW0RD=QRC7Y94A/UIC=[033,066] - 

_UAF> /DEVICE=DISK$INVENT/DIRECTORY=[INV]/LGICMD=INVENTORY - 

_UAF> /FLAGS=CAPTIVE/NOACCESS=(PRIMARY. 18-8, SECONDARY, 0-23) 

In this example, the /FLAGS and /NOACCESS qualifiers are used to restrict 
users from logging in to the turnkey account. The /NOACCESS qualifier 
limits logins to specific hours (see Section 5.5.5). The /FLAGS=CAPTIVE 
qualifier adds the login flag CAPTIVE to the turnkey account record. The 
CAPTIVE flag locks the person using the account into the application 
software by 

• Disabling the CTRL/Y function to prevent users from interrupting the 
execution of the command procedure and gaining access to the command 
interpreter 

• Preventing the user from specifying an alternate command interpreter with 
the /CLI qualifier at login time 

• Preventing the user from specifying an alternate default disk device with 
the /DISK qualifier at login time 
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You may also want to disable mail and welcome notices with the 
/FLAGS=(DISNEWMAIL,DISWELCOME) qualifier. 


5.4 Using a Command Procedure to Add a User Account 

For consistent results, you can incorporate the steps for adding a user account 
(interactive or turnkey) into a command procedure similar to that shown in 
Example 5-4. 
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Example 5-4 Command Procedure for Adding a User 


! ADDUSER.COM -- Adds a new user to the system authorization file 

; 

USERDISK = "WRKD$:" ! Default disk for new users 

UAF = "$AUTH0RIZE" 

ON C0NTR0LY THEN GOTO CLEANUP 
ON WARNING THEN GOTO CLEANUP 
OLDDIR = F$ENVIR0NMENT("DEFAULT") 

PREVPRIV = F$SETPRV("SYSPRV") 

IF .NOT. F$PRIVILEGE("SYSPRV") THEN GOTO NOPRIV 
SET DEFAULT SYS$SYSTEM 

i 

! Request account information 

i 

INQUIRE USERNAME "Username" 

INQUIRE FULLNAME "Full name" 

SET TERMINAL/NOECHO 

INQUIRE PASSWORD "Password ["Username■]" 

SET TERMINAL/ECHO 

IF PASSWORD .EQS. "" THEN PASSWORD = USERNAME 
GET.GRP: 

INQUIRE GRP "UIC Group Number" 

IF GRP .EQS. "" THEN GRP = 

WRITE SYSSOUTPUT "" 

WRITE SYS$OUTPUT "Determine the UIC from the following listing:" 
WRITE SYSIOUTPUT "" 

UAF SHOW ['GRP',*]/BRIEF 
INQUIRE UIC 

IF UIC .EQS. "" THEN GOTO GET.GRP 
IF F$L0CATE("[",UIC) .EQ. F$LENGTH(UIC) .AND. - 

F$L0CATE("<",UIC) .EQ. F$LENGTH(UIC) THEN UIC = "[" + UIC + "]" 
INQUIRE ACCOUNT "Account Name [VMS]" 

IF ACCOUNT .EQS. "" THEN ACCOUNT = "VMS" 

INQUIRE PRIVS "Privileges [NONE]" 

IF PRIVS .NES. "" THEN PRIVS * "/PRIV=(" + PRIVS + ")" 

USERDIR = FSEXTRACT(0,9,USERNAME) 

INQUIRE TMP "Login Directory ["USERDIR']" 

IF TMP .NES. "" THEN USERDIR = TMP 
INQUIRE TMP "Login Device ["USERDISK']" 

IF TMP .NES. "" THEN USERDISK = TMP 
DQUOTA = 0 

IF F$SEARCH(" "USERDISK'[0,0]QU0TA.SYS") .EQS. "" THEN GOTO NQO 
DQUOTA = 1 

i 

! Request disk quota entry information 

i 

INQUIRE QUOTA "Disk Quota [1000]" 

IF QUOTA .EQS. "" THEN QUOTA = 1000 
INQUIRE OVERDRAFT "Overdraft Quota [100]" 

IF OVERDRAFT .EQS. "" THEN OVERDRAFT = 100 
OPEN/WRITE FILE SYS$LOGIN:ADDQUOTA.TMP 
WRITE FILE "RUN SYS$SYSTEM:DISKQUOTA" 


(Continued on next page) 
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Example 5-4 (Cont.) Command Procedure for Adding a User 


* ! 

$ !Add quota entry 

$ ! 

$ WRITE FILE "USE "USERDISK"' 

$ WRITE FILE "ADD ",UIC,"/PERMQUOTA=",QUOTA,"/OVERDRAFT®",OVERDRAFT 
$ CLOSE FILE 

$ <BSYS$LOGIN: ADDQUOTA. TMP 

$ DELETE SYSlLOGIN:ADDQUOTA.TMP;*/N0L0G 

$NQO: 

$ ! 

$ ! Create a first-level directory for the account 

$ ! 

$CREATE/DIRECTORY/0WNER_UIC='UIC'/PROTECTION®(S=RWE,0=RWE,G=RE,W)- 
•USERDISK'['USERDIR']/LOG 

$ IF F$SEARCH("SYS$MANAGER:LGISAMPL.COM") .EQS. "" THEN GOTO ADDACC 

$ ! 

$ ! Copy the LOGIN.COM template to user account 

$ • 

$ COPY SYS$MANAGER:LGISAMPL.COM 'USERDISK'['USERDIR']LOGIN.COM 
$ SET FILE/OWNER_UIC='UIC' 'USERDISK'['USERDIR']LOGIN.COM; !Change the UIC 

$ * 

$ ! Add the account record to the UAF 

$ ! 

$ADDACC: 

$ OPEN/WRITE FILE SYS$L0GIN:ADDUAF.TMP 
$ WRITE FILE "RUN SYS$SYSTEM:AUTHORIZE" 

$ WRITE FILE "ADD ".USERNAME,"/OWNER®""».FULLNAME,"""/ACCOUNT®".ACCOUNT,- 
"/DEVICE®''USERDISK'/DIRECTORY®[''USERDIR']/UIC®",UIC.PRIVS,- 
"/PASSWORD®".PASSWORD 
$ CLOSE FILE 
$ «SYS$L0GIN:ADDUAF.TMP 
$ DELETE SYS$L0GIN:ADDUAF.TMP;*/N0L0G 
$ ! 

$ ! Restore prior working environment 

$ ! 

SCLEANUP: 

$ SET TERMINAL/ECHO 
$ PREVPRIV = F$SETPRV(PREVPRIV) 

$ SET DEFAULT 'OLDDIR' 

$ EXIT 

$ ! 

$ ! In case proper privileges are not set 

$ ! 

$N0PRIV: 

$ WRITE SYSIOUTPUT "You need SETPRV or SYSPRV privilege to run this procedure" 
$ GOTO CLEANUP 


5.5 Maintaining the User Environment 

As the work requirements of your system change, you may need to 

• Create additional default records to serve as templates for new categories 
of users 

• Delete or disable the accounts of users who leave your site 

• Impose login restrictions to limit system use by certain accounts 

With the Authorize Utility, you can perform these maintenance operations by 
modifying or deleting records in the UAF. 
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As part of the job of maintaining the user environment, you may also want 
to periodically check the disk structure for lost files or files in need of repair. 
To perform these operations, you use the Verify Utility, as described in 
Section 5.5.4. 


5.5.1 Creating Additional Default Record Templates 

On systems where all users perform the same type of work, you typically use 
the system-supplied default record, DEFAULT, as the template for adding 
new user records. You may find, however, that your system supports several 
different user categories, each category performing a specific type of work 
and requiring unique record attributes. Instead of always using the system- 
supplied default record as a template and making numerous changes each 
time you add a user record, you can create additional default UAF records to 
serve as templates for each user category. 

Before you create additional default records, you must first decide 

• What the individual user categories are 

• What attributes are common to each category 

• What to name the default records 

Once you define a user category and establish which record attributes are 
needed, you can create the default record. For example, the following 
command creates a default record for a category of user that requires a 
special captive account: 

UAF> ADD DEFAULT2/LGICMD=ALT_C0M_PR0C/FLAGS=CAPTIVE - 
_UAF> /DEVICE=USER3:/DIRECTORY=[PRODUCT] 

The command in this example uses the system-supplied default record 
DEFAULT to create the record DEFAULT2, and changes the LGICMD, 
login flags, default device, and default directory fields. The AUTHORIZE 
command COPY can then be used to create additional records having the 
same attributes as DEFAULT2. 

The COPY command creates a new UAF record that duplicates the specified 
default record except where you explicitly override field values. For example, 
you could use the following command to create a record for a new user that 
duplicates the default record DEFAULT2: 

UAF> COPY DEFAULT2 PAL00KA/PASSW0RD=W7YA84MI/UIC=[360,114] 

This example uses DEFAULT2 as a template to create a duplicate record for 
the user PALOOKA. Notice that the only values that are changed are those 
for password and UIC. 


5.5.2 Deleting a User Account 

The main problem in deleting an account, especially an interactive account, is 
cleaning up the files used by the account. The following steps are suggested: 

1 Copy (or have the outgoing user of the account copy) any files of value 
to the ownership of another account. You should be sure to change the 
owner UIC of the files to match the owner UIC of the new owner. You 
can also use the Backup Utility (BACKUP) to copy the files to a backup 
tape or disk. 
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2 Set your UIC to that of the account to be deleted and remove all 
privileges, or else change the password and log in as a user of that 
account. This is especially important if you are using a command 
procedure similar to the one in Example 5-5. 

3 Delete the account's files and directories from the deepest level up to the 
top level, using the following procedure: 

a Locate and examine all subdirectories using the DCL command 

DIRECTORY [default . . . ], where default is the name of the account's 
default directory. 

b Delete the files in each subdirectory and then delete the subdirectory. 
Note that directory files are protected against owner deletion, therefore, 
you must change the protection before deleting directory files. 

c Delete the account's first-level directory. Example 5-5 illustrates a 
command procedure that deletes an account's files from the bottom 
level up. 

Note: The command procedure in Example 5-5 should not be executed by 
a privileged user. 

4 Remove the account, using the Authorize Utility. 

5 Remove the user's disk quota entry from the disk quota file, if one existed, 
with the Disk Quota Utility. 

6 Remove associated VAXmail information. 

Example 5-5 Command Procedure Template for Deleting an 
Account's Files 


$ ! DELTREE.COM - deletes a complete directory tree 

$ • 

$ ! PI = pathname of root of tree to delete 

$ • 

$ ! All files and directories in the tree, including 

$ ! the named root, are deleted. 

$ ! 

$ IF ""DELTREE'" .EQS. " M THEN DELTREE = "<DSYS$LIBRARY:DELTREE" 
$ ON C0NTR0L.Y THEN GOTO DONE 
$ ON WARNING THEN GOTO DONE 

$ DEFAULT = F$L0GICAL("SYS$DISK") + F$DIRECT0RY() 

$10: 

$ IF PI .NES. "" THEN GOTO 20 
$ INQUIRE PI "Root" 

$ GOTO 10 
$20: 

$ IF F$PARSE(P1) .EQS. "" THEN OPEN FILE ’PI' 

$ SET DEFAULT 'PI' 

$L00P: 

$ FILESPEC * F$SEARCH("*.DIR;1") 

$ IF FILESPEC .EQS. "" THEN GOTO L00PEND 
$ DELTREE [.'F$PARSE(FILESPEC..,"NAME")'] 

$ GOTO LOOP 
$L00PEND: 

$ IF F$SEARCH("*.*;*") .NES. "" THEN DELETE *.*;* 

$ DIR = (F$DIRECT0RY()-"]-F$PARSE("[-]" , , , - 
"DIRECTORY")-"] »-">»)-« . 

$ SET PR0TECTI0N=W0RLD:RWED [-]'DIR'.DIR;1 
$ DELETE [-]'DIR'.DIR;1 
$D0NE: 

$ SET DEFAULT 'DEFAULT' 
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If you never assign multiple users the same UIC, you can use the Backup 
Utility to remove the user's files, even if the files are scattered throughout 
the directory structure. See the VAX/VMS Backup Utility Reference Manual 
for more information. To remove files using BACKUP, issue the command 
shown in this example: 

$ BACKUP/DELETE PUBLIC:[...]/0WNER=[21,103] MTAO:PUBLICUIC.SAV 

This BACKUP command copies and deletes only those files owned by the 
specified UIC on disk PUBLIC. The files are copied into a save set named 
PUBLICUIC on device MTAO. 


5.5.3 Disabling a User Account 

If it becomes necessary to disable an account, but deleting it at present would 
be undesirable, use AUTHORIZE to set the disable user flag 
(/FLAGS=DISUSER). If the user is logged in, the account is disabled only 
after the user logs out. 

Disabling a powerful yet infrequently used account provides an extra security 
measure by eliminating the risk of guessed or stolen passwords. 


5.5.4 Recovering Lost Files 

Under normal circumstances, files should not become lost. However, files 
occasionally may be lost due to disk corruption, hardware problems, or 
user inexperience. For example, in cleaning up files and directories, you 
may inadvertently delete directories that still point to files. When you 
delete a directory file (a file with the file type DIR) without first deleting 
its subordinate files, the files referred to by that directory become lost files — 
files that remain on the disk but are not referenced by any directory. Lost 
files are often obsolete files that consume disk space and act as debits against 
a user's disk quota. 

You can recover lost files by issuing the Verify Utility command: 

ANALYZE/DISK.STRUCTURE/REPAIR/CONFIRM device-name: 

See the VAX/VMS Verify Utility Reference Manual for a detailed description of 
the ANALYZE/DISK-STRUCTURE command. 

This command, which requires BYPASS privilege, places lost files in a 
directory named [SYSLOST]. This directory resides in the disk's master 
file directory (000000), and is created by the Verify Utility when a lost file is 
recovered. 

To restore lost files to the [SYSLOST] directory, issue the command shown in 
this example: 

$ ANALYZE/DISK.STRUCTURE/REPAIR/CONFIRM DDAO: 
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The Verify Utility returns the following messages and prompts you for the 
appropriate action: 

'/.VERIFY-1-LOSTHEADER, file (408,39,1) SUB_A.DIR;1 
Not found in directory 
Delete or Repair this error (D,Y,N): 

'/.VERIFY-1-LOSTHEADER, file (429,4,1) ALPHA.DAT;4 
Not found in directory 
Delete or Repair this error (D,Y,N): 

7.VERIFY-1 - LOSTHEADER, file (435,13,1) OMEGA.DAT;2 
Not found in directory 
Delete or Repair this error (D,Y,N): 

To write the lost files to [SYSLOST], specify YES or Y in response to the 
prompt Delete or Repair this error QD,Y,N):. You can then copy, rename, or 
back up the lost files from [SYSLOST] to another directory. The file owner 
requires no special privileges to copy the files from [SYSLOST], as the files 
still retain the original owner UIC. A minimum of RE AD ALL privilege is 
required, however, to display the contents of the SYSLOST directory. 

As system manager, you should periodically use the Verify Utility command 
ANALYZE/DISK_STRUCTURE/REPAIR/CONFIRM to check for the 
presence of lost files on the disk. Another opportunity to check for lost 
files is during a Backup operation. See the VAX/VMS Backup Utility Reference 
Manual for complete descriptions of the Backup commands and qualifiers. 

The following Backup command returns a formatted listing of the files in the 
Backup save set as the operation proceeds: 

BACKUP/IMAGE/LIST device.A: device JB:saveset.sav/SAVESET 

Lost files appear at the end of the save set listing as files with empty brackets, 
indicating that they are not found within any directory. For example: 

[ ]SUB_A.DIR;1 
[ ]ALPHA.DAT;4 
[ ]OMEGA.DAT;2 

End of saveset 


5.5.5 Restricting the Use of Accounts 

Often workload schedules dictate the days and times your system is used to 
perform specific operations. Depending on the nature of the work performed 
at your site, you may want to control when certain users are allowed to log in. 
Using the Authorize Utility, you can place controls in the login characteristics 
fields of the UAF record to restrict the days and times a user can log in and to 
inhibit certain login functions. 

For a detailed description of the qualifiers used to restrict the use of accounts, 
see the discussion of the Authorize Utility in the VAX/VMS Authorize Utility 
Reference Manual. The next sections discuss some of the most common 
restrictions. 
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5.5.5.1 Setting Day Types 

You restrict the use of certain accounts by defining the days of the week 
as either PRIMARY or SECONDARY, and then assigning login restrictions 
to these defined day types. For example, if you define the days Saturday 
and Sunday as SECONDARY days, then any restrictions you assign to the 
SECONDARY day type apply to both. 

There are two types of login restrictions that you can assign to either day 
type: 

• Time restrictions—Limit logins to specific hours of the day 

• Function restrictions—Limit types of login 

By default, in every user record, the five weekdays (Monday through Friday) 
are defined as PRIMARY days, and the two weekend days (Saturday and 
Sunday) are defined as SECONDARY days. 

The way you define days and assign restrictions depends on your site. For 
example, suppose that on weekdays your system supports a large number of 
interactive users, but on weekends it is used for certain operations that require 
dedicated system resources. By assigning restrictions to the SECONDARY day 
type, you can restrict users from accessing the system during the days defined 
as SECONDARY. You can change these day type definitions for any account 
using the following AUTHORIZE qualifier: 

/PRIMEDAYS=([NO]day[,...]) 

The /PRIMEDAYS qualifier uses a list of day names to define the PRIMARY 
and SECONDARY days of the week. To define a day as a SECONDARY day, 
use the prefix NO before the day name. Any days that you omit from the list 
take their default value. 


5.5.5.2 Restricting Logins to Specific Times 

By default, there are no restrictions on login hours. You can specify login 
time restrictions using the following AUTHORIZE qualifiers: 


Qualifier 

Meaning 


/[NO]ACCESS 

Specifies access hours for all modes of logins 


/[NOJDIALUP 

Specifies access hours for interactive logins via dialup 
terminals 

/[NOJINTER ACTIVE 

Specifies access hours for interactive logins via any 
terminal 

/[NOjLOCAL 

Specifies access hours for interactive logins via 
terminals 

local 

/[NOJREMOTE 

Specifies access hours for interactive logins via 
remote terminals (SET HOST) 

network 


Any user still logged in when the access time has expired, will receive the 
following warning message, and have two minutes to log out before their 
process is terminated by the job controller. 

JBC-W-RESTRICT, UAF restricts access at this time, please log out immediately 
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5.5.5.3 Restricting Login Functions 

In addition to specifying hourly login restrictions, you can also assign function 
restrictions to an account by using appropriate keywords with the /FLAGS 
qualifier in the Authorize Utility. By default, there are no restrictions. Options 
are 


Keyword 

[NO]AUDIT 

AUTOLOGIN 

[NOJCAPTIVE 

[NO]DEFCLI 

[NOJDISCTLY 

[NO]DISNEWMAIL 

[NOJDISREPORT 

[NO]DISUSER 

[NO]DISWELCOME 

[NOJGENPWD 

[NOJLOCKPWD 

[NO]DISMAIL 

[NO]PWD_EXPIRED 

[NO]PWD2 EXPIRED 


Meaning 

[Do not] audit all security-relevant actions 

Makes account available only by using the autologin 
mechanism 

[Do not] prevent user from changing any defaults at login 

[Do not] prevent user from changing default CLI or CLI 
tables 

[Do not] disable CTRL/Y interrupts 

[Do not] suppress "New Mail ..." announcements 

[Do not] report login information (last login date, login 
failures, and so on) 

[Do not] disable the account completely 

[Do not] suppress "Welcome to ... login message 

[Do not] require user to use generated passwords 

[Do not] prevent user from changing password 

[Do not] prevent mail delivery to the user 

[Do not] mark password as expired 

[Do not] mark second password as expired 


If the AUTOLOGIN flag is set, the following forms of access are disabled: 

• Login by any terminal, LAT connection, or SET HOST by entering user 
name and password 

• Access by DECnet task using explicit access control 

The following forms of access remain enabled: 

• Interactive login by the autologin mechanism 

• Batch jobs 

• Proxy access by DECnet task 


5.6 UAF Login Checks 

To help you understand the effect of login restrictions, this section explains 
how the system checks the login fields of the UAF when a user attempts to 
log in. 

When a user activates a terminal (by turning it on and pressing RETURN 
if directly connected, or by dialing in to a system and observing the remote 
connect protocol), and that terminal is not allocated by a user process, the 
system prompts for a name and password. The person using the terminal 
must type a name and password combination that exists in a UAF record, or 
the system denies him further access. If the name and password are accepted, 
the system then performs the following operations: 
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1 Examines the login flags, beginning with DISUSER. If DISUSER is 
set, the login attempt fails. Note that setting this flag for powerful, 
infrequently used accounts (such as SYSTEM, SYSTEST, and FIELD) 
virtually eliminates the risk of guessed passwords for those accounts. 

2 If the DISUSER flag is not set, verifies primary or secondary day 
restrictions. After checking the current day type, the system determines 
whether hourly login restrictions are in effect (as defined by the /ACCESS, 
/DIALUP, /INTERACTIVE, /LOCAL, and /REMOTE qualifiers). If 

the current hour is restricted, the login fails immediately. Otherwise it 
succeeds. 

3 If the login is successful, passes control to the command interpreter (for 
example, DCL) named in the user's UAF record. 

4 Checks whether SYS$SYLOGIN is defined. If so, the logical name 
is translated (in most cases to SYS$MANAGER:SYLOGIN.COM) and 
that procedure is executed. When the procedure completes, the system 
searches for the name of a login command procedure in that user's UAF 
record. If a command procedure is specified in the LGICMD field and that 
procedure exists, it is executed. Otherwise, if the LGICMD field is blank, 
the user's command file named LOGIN is executed automatically (if it 
exists). 

After a successful login, the command interpreter prompts for user input 
(DCL usually displays a dollar sign) and the user responds with commands 
acceptable to the command interpreter. (DCL accepts those commands 
documented in the VAX/VMS DCL Dictionary.) However, the system prohibits 
activities that violate the user's privilege allowance or exceed resource quotas. 


5.7 Alternate Login Procedures 

There are situations when normal login activities using the UAF are either 
impossible or undesirable. The UAF may be inaccessible for some reason, or 
you may want to boot for standalone functions using an alternate UAF that 
restricts access to the system. This section discusses these two situations. 

If the UAF is locked, disabled, or not present, you can log in on the console 
terminal with any name and password. The system assigns the following 
values to your user account: 

• Name—Your user name 

• UIC—[001,004] 

• Command interpreter—DCL 

• Login flags—None 

• Priority—Value of the system parameter DEFPRI 

• Resources—Values of the PQL system parameters 

• Privileges—All 

The process name is normally the name of the device on which you logged 
in, that is, _OPAO. 
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If you want to take the system for standalone use, you can select, at bootstrap 
time, an alternate UAF named SYS$SYSTEM:SYSUAFALT.DAT by using a 
system parameter file in which the UAF ALTERNATE parameter has a value 
of 1. You can also change this value to 1 during a conversational bootstrap 
operation. (See Section 11 for information on creating system parameter files.) 
Note that a file named SYSUAFALT in UAF format must exist at bootstrap 
time. (The system initially changes to the alternate UAF by assigning 
SYSUAF as a logical name for SYSUAFALT.) If the UAFALTERNATE 
parameter is set at bootstrap time and no alternate UAF exists, the system 
behaves like an open system. 

You can create or modify an alternate UAF with the following commands: 

$ SET DEFAULT SYS$SYSTEM 
$ DEFINE SYSUAF SYSUAFALT 
$ RUN AUTHORIZE 

Any time after booting the system with an alternate UAF, you can switch to 
the standard UAF (that is, SYS$SYSTEM:SYSUAF.DAT) with the following 
DCL command: 

$ DEASSIGN SYSUAF/SYSTEM 

You can also switch to the alternate UAF after bootstrap time with the 
following DCL command: 

$ DEFINE/SYSTEM/EXEC SYSUAF SYSUAFALT 

(For this mode of operation, the alternate UAF can have any file name.) 


5.8 Creating Proxy Accounts 

A proxy login account allows users on a remote node in a network to access 
data by way of a local account on your system. Proxy accounts are useful 
when you want to grant one or more users on a remote node access to specific 
files but find it undesirable to provide them with a private account on your 
system. You establish and control proxy accounts with the Authorize Utility. 

With proxy accounts, you can authorize one or more users on a remote node 
to issue DCL commands that access data from a particular account on your 
system. Proxy accounts allow remote users to access specific local data (for 
example, type and print files) without having to log in to your system or use 
an access control string. Remote users assume the same file access rights as 
the local account and also receive the default privileges of the local account. 
The following sections explain the procedures for setting up proxy accounts. 


5.8.1 Creating a Network User Authorization File 

Proxy accounts exist as records in a network UAF called 
SYS$SYSTEM:NETUAF.DAT and are created and maintained using the 
Authorize Utility. Since the network UAF is not provided with the 
distribution kit, you must create and initialize it. You use the AUTHORIZE 
command CREATE/PROXY for this operation. 

Proxy accounts must be associated with a user account in the SYSUAF.DAT 
file on your local system. You will probably want to create a "standard 
access" account in the UAF for proxy accounts. For example, you could create 
an account named REMOTE—MARKET with limited privileges, which allows 
access to certain data files on your local system. 
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Suppose you have a group of users on your local system who prepare 
marketing reports, and who rely on input from users on other systems. You 
would assign the REMOTE—MARKET account in SYUAF.DAT the same 
group number and default privileges you assign to the local marketing group. 
In this way, the remote contributors could access any data files that are 
"owned" by users in your marketing group and that are not protected from 
GROUP access. 


5.8.2 Adding Proxy Accounts 

You create a proxy account by adding records to the network UAF that equate 
one or more users on a remote node to users on your home node. 

For example, the following command adds a user proxy account: 

UAF> ADD/PROXY HAL::WALTER REMOTE.MARKET 

Assume that you have created an account named REMOTE—MARKET 
on your home node. The record created in this example permits the user 
WALTER on remote node HAL to access data by way of the 
REMOTE—MARKET account on your home node. With the proxy account, 
WALTER can access any data from his node that REMOTE—MARKET can 
access locally. 

Note: Since the remote user receives the same privileges as the local user, you 
should not set up proxy accounts associated with local accounts that have 
special privilege. Granting remote users such access powers poses a threat 
to the security of your system. 

When creating such an account, remember that each user on a remote 
node is allowed access to only one account on the local node. So, in the 
previous example, HAL::WALTER is allowed access only to the files that 
REMOTE—MARKET can access. If you tried to add another proxy account for 
HAL::WALTER, you would receive an error message. 

A number of your users may have accounts on a remote node and require 
ready access to their local files. You can create a network authorization record 
that grants access to each of them, provided that the user name on your 
system is the same as the user name on the remote node. The following form 
of the ADD/PROXY command adds such a record: 

UAF> ADD/PROXY HAL::* * 

This command authorizes any user on the remote node HAL to access any 
account with the same user name on your system. 

Similarly, you might want to permit this sort of access for just one user. 

UAF> ADD/PROXY HAL::BARBARA * 

In this case, the user BARBARA on node HAL can access any files that 
BARBARA (and only BARBARA) can access on your system. 
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5.8.3 Controlling Proxy Logins 

Whenever a proxy login request occurs, the system verifies that proxy 
access on the participating nodes is enabled. (By default, both incoming 
and outgoing proxy access is enabled for each node.) If access is enabled, 
the system checks account information in your NETUAF.DAT. You can, 
however, change proxy access or disable it totally by using the Network 
Control Program (NCP). Use of NCP to control proxy access is described in 
the VAX/VMS Networking Manual 
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This chapter contains detailed descriptions of the resource control attributes 
that you can assign to a user process when creating a record in the UAF: 

• Limits on reusable system resources 

• Base priority for scheduling user processes 

• Privileges allowing use of restricted and sensitive system functions 

In addition, this chapter discusses the accounting log file as a tool for tracking 
resource use. 


6.1 Setting Limits on Reusable System Resources 

Each user of the system is limited in the consumption of such resources 
as system memory. You set limits when you define the user to the system 
through the creation of an account in the UAF. 

Limits control the way in which a process shares its allotment of a resource 
with the subprocesses that it creates. In addition to restricting the number 
of processes that a single user or account may have at any given time, the 
system uses four types of limits for sharing resources: 

• Pooled —If the limit on the use of a resource is pooled, a process and 
created subprocesses share the total limit on a first-come, first-served 
basis. 

• Deductible —If the limit on the use of a resource is deductible, a 
subprocess is allotted a portion of the total limit; the portion given to 
the subprocess is deducted from the total limit. 

• Nondeductible —If the limit is nondeductible, the subprocess is allotted 
the total limit of the creating process; there is no deduction from the 
allotment of the creating process. 

• systemwide —If the limit is systemwide, a process and all created 
subprocesses with the same user name or account share the total limit 
on a first-come, first-served basis. 

In creating a UAF record, you assign values to the limits shown in Table 6-1. 
These limits are described in the following sections. Usually, you simply 
assign the default values for these limits. However, see the Guide to 
VAX/VMS Performance Management for a discussion of how to evaluate 
and adjust the limits in the context of performance optimization strategies. 

Table 6-1 summarizes each of these limits, the suggested value, and the type 
of limit. 
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Table 6-1 Process Resource Limits, Suggested Values, Types, 
and Descriptions 


Limit 

Value 

Type 1 

Description 

ASTLM 

24 

N 

AST queue limit 

BIOLM 

18 

N 

Buffered 1/0 count limit 

BYTLM 

8192 

P 

I/O byte count limit 

CPU 

0 

D 

CPU time limit (0 = no limit) 

DIOLM 

18 

N 

Direct I/O count limit 

ENQLM 

30 

P 

Enqueue quota 

FILLM 

20 

P 

Open file limit 

JTQUOTA 

1024 

P 

Initial byte quota for jobwide logical name 
table 

MAXACCTJOBS 

0 

S 

Maximum active processes for a single 
account (0 = no limit) 

MAXDETACH 

0 

S 

Maximum detached processes for a single 
user name (0 = no limit) 

MAXJOBS 

0 

S 

Maximum active processes for a single 
user name (0 = no limit) 

PGFLQUO 

12800 

P 

Paging file limit 

PRCLM 

2 

P 

Subprocess creation limit 

SHRFILLM 

0 

P 

Maximum number open shared files 
(0 = no limit) 

TQELM 

10 

P 

Timer queue entry limit 

WSDEF 

200 

N 

Default working set size 

WSEXTENT 

1000 

N 

Working set extent 

WSQUO 

500 

N 

Working set quota 

1 D=deductible, N = 

= nondeductible, P= 

= pooled, S=systemwide 


6.1.1 AST Queue Limit (ASTLM) 

The AST queue limit (ASTLM) limits the sum of the following: 

• The number of asynchronous system trap (AST) requests that a user's 
process can have outstanding at one time 

• The number of scheduled wakeup requests that a user's process can have 
outstanding at one time 

This limit affects not only all system services that accept an AST address as 
an argument, but also the Schedule Wakeup ($SCHDWK) system service. 

If the deferred write option (DFW) is enabled, the number of ASTs used per 
file is equal to 1, plus the number of record streams, plus the multibuffer 
count. Otherwise, the number is 1 plus the number of record streams. 

ASTLM is a nondeductible limit with a suggested typical value of 24. 
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6.1.2 Buffered I/O Count Limit (BIOLM) 

The buffered I/O count limit (BIOLM) limits the number of outstanding 
buffered I/O operations permitted a user's process. 

In a buffered I/O operation, the data transfer takes place from an intermediate 
buffer in the system pool, not from a process-specified buffer. Buffered 
operations for a user process include terminal I/O, file system and network 
I/O, card reader input, and unspooled printer output. During a buffered 
I/O operation, the pages containing the process-specified buffer need not be 
locked in memory. 

BIOLM is a nondeductible limit with a suggested typical value of 18. 


6.1.3 Buffered I/O Byte Count Limit (BYTLM) 

The buffered I/O byte count limit (BYTLM) limits the amount of buffer space 
that a user's process can use. 

This buffer space is used for buffered I/O operations and for the creation 
of temporary mailboxes. It also limits the number of mapping windows the 
user can create as segmented (or cathedral) windows. Cathedral windows are 
primarily useful to reduce the overhead required to read large files. 

BYTLM is a pooled limit with a suggested typical value of 8192. 


6.1.4 CPU Time Limit (CPU) 

The CPU time limit (CPU) limits the amount of CPU time that a user's 
process can use per interactive session or batch job. 

The time must be specified in abbreviated delta format—hh:mm:ss:cc. 

CPU is a deductible limit with a suggested typical value of 0 (no limit), 
but the value only applies to this instance or other instances of the user's 
processes. CPU is not cumulative across separate sessions or batch jobs. 


6.1.5 Direct I/O Count Limit (DIOLM) 

The direct I/O count limit (DIOLM) limits the number of outstanding direct 
I/O operations permitted a user's process. 

In a direct I/O operation, the data transfer takes place directly from a process- 
specified buffer. Direct I/O operations for a user process typically include 
disk and tape I/O. The pages containing this buffer are locked in memory by 
the operating system during the direct I/O operation. 

DIOLM is a nondeductible limit with a suggested typical value of 18. 
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6.1.6 Enqueue Quota (ENQLM) 

The enqueue quota (ENQLM) limits the number of locks a process (and its 
subprocesses) can own. VAX Record Management Services (RMS) uses the 
Lock Management Facility to synchronize shared file access, global buffers, 
and record locks. Because VAX RMS takes out one lock for every shared 
file, local buffer, global buffer section, and outstanding record lock, users 
who expect to perform large amounts of VAX RMS file sharing should have 
ENQLM set to a large value. 

If your process performs extensive VAX RMS file sharing without sufficient 
enqueue quota, you could receive the SS$_EXENQLM error message. 
Furthermore, if your system performs extensive VAX RMS file sharing 
and the value of the LOCKIDTBL system parameter is too low, you could 
receive the SS$_NOLOCKID error message. Note that whenever you 
increase the value of LOCKIDTBL, you may have to increase the value 
of the RESHASHTBL system parameter (see the discussion of the System 
Generation Utility (SYSGEN) in the VAX/VMS System Generation Utility 
Reference Manual). 

For shared files, the value of ENQLM should represent the number of files 
open as shared multiplied by the number of locks per process per file. If you 
use the default multibuffer counts, you can estimate the number of locks as 4 
for indexed sequential files and 3 for relative files. If you use other than the 
default value for the multibuffer counts, you can estimate the number of locks 
per process per file as one per file plus the multibuffer count for that file plus 
the number of records locked (which is usually one). Use the DCL command 
SHOW RMS_DEFAULT to display the default multibuffer counts. 

ENQLM is a pooled limit with a suggested typical value of 30. 


6.1.7 Open File Limit (FILLM) 

The open file limit (FILLM) limits the number of files that a user's process 
can have open at one time. This limit includes the number of network logical 
links that can be active at the same time. 

FILLM is a pooled limit with a suggested typical value of 20. Note that each 
open file also requires at least 96 bytes of BYTLM. 


6.1.8 Job Table Quota (JTQUOTA) 

The job table quota (JTQUOTA) specifies the initial byte quota with which the 
jobwide logical name table is to be created. 

JTQUOTA is a pooled quota with a suggested typical value of 1024. 


6.1.9 Maximum Account Jobs Limit (MAXACCTJOBS) 

The maximum account jobs limit (MAXACCTJOBS) specifies the maximum 
number of batch, interactive, and detached processes that may be active at 
one time for all users of a single account. 

MAXACCTJOBS is a systemwide limit with a suggested typical value of 0. 
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6.1.10 Maximum Detached Processes Limit (MAXDETACH) 

The maximum detached processes limit (MAXDETACH) specifies the 
maximum number of detached processes that may be active at one time 
for a single user name. Processes that exceed this limit are terminated. 

MAXDETACH is a systemwide limit with a suggested typical value of 0. 


6.1.11 Maximum Process Jobs Limit (MAXJOBS) 

The maximum process jobs limit (MAXJOBS) specifies the maximum number 
of interactive, batch, and detached processes that can be active at one time for 
a user name. Processes that exceed this limit are terminated. 

MAXJOBS is a systemwide limit with a suggested typical value of 0. 


6.1.12 Paging File Limit (PGFLQUO) 

The paging file limit (PGFLQUO) limits the number of pages that the user's 
process can use in the system paging file. The paging file provides temporary 
disk storage for pages forced out of memory by a memory management 
operation. PGFLQUO limits the total virtual address space that can be 
created using the Create Virtual Address Space ($CRETVA) or Expand 
Program/Control Region ($EXPREG) system services. 

PGFLQUO is a pooled limit with a suggested typical value of 12800. 


6.1.13 Subprocess Creation Limit (PRCLM) 

The subprocess creation limit (PRCLM) limits the number of subprocesses a 
user's process can create. 

The process that is created when a user logs in to the system can in turn 
create subprocesses. These subprocesses are all accountable to the user and 
share the resources allotted to the initial process. 

PRCLM is a pooled limit with a suggested typical value of 2. 


6.1.14 Shared Files Limit (SHRFILLM) 

The shared files limit (SHRFILLM) specifies the maximum number of shared 
files that an account may have open at one time. The shared files limit is a 
pooled limit with a suggested typical value of 0. 
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6.1.15 Timer Queue Entry Limit (TQELM) 

The timer queue entry limit (TQELM) limits the sum of the following: 

• The number of entries that a user's process can have in the timer queue 

• The number of temporary common event flag clusters that a user's process 
can have 

This limit does not govern the creation of permanent event flag clusters. 

Timer queue entries are used in time-dependent scheduling; common event 
flags are used in synchronizing activities among groups of cooperating 
processes. 

TQELM is a pooled limit with a suggested typical value of 10. 


6.1.16 Default Working Set Size (WSDEF) 

The default working set size (WSDEF) sets the initial working set size limit 
for a user's process. 

WSDEFAULT is a nondeductible limit with a suggested typical value of 200 
pages. If the value specified exceeds the value of WSQUOTA (see Section 
6.1.18), the lesser value is used. 


6.1.17 Working Set Extent (WSEXTENT) 

The working set extent (WSEXTENT) specifies the maximum size to which 
a user's physical memory usage can grow, independent of the system load. 
This enlargement of the physical memory for a user is accomplished by the 
Adjust Working Set Limit ($ADJWSL) system service, and is normally done 
for the user by VAX/VMS in response to heavy page faulting by the user. 

WSEXTENT is a nondeductible quota with a suggested typical value of 1000 
or more. This value should always be greater than or equal to WSQUOTA. 
The value is controlled by the system parameter WSMAX. 


6.1.18 Working Set Quota (WSQUOTA) 

The user's physical memory usage can grow on a typically loaded system. 
That is, this parameter guarantees the user that the number of physical pages 
specified will be available. For example, WSQUOTA limits the number of 
pages a user can lock in memory. 

WSQUOTA is a nondeductible quota with a suggested typical value of 500. 
This value should be greater than or equal to WSDEFAULT. The value is 
controlled by the system parameter WSMAX. 
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6.2 Setting Priorities for User Processes 

A user's priority is the base priority used in scheduling the process that the 
system creates for the user. There are 32 levels of software priority in the 
VAX/VMS system, 0 through 31. The highest priority is 31; the lowest is 0. 
The range of priorities for timesharing processes is 1 through 15; the range 
for real-time processes is 16 through 31. 

Processes with real-time priorities are scheduled strictly according to base 
priority; in other words, the executable real-time process with the highest 
base priority is executed first. Processes with timesharing priorities are 
scheduled according to a slightly different principle, to promote overlapping 
of computation and I/O activities. 

In the user's account record of the UAF, the default value of a user's priority 
is 4; for practical purposes, the minimum value is 1. You should ensure that 
the priority for timesharing users remains at the default. Note that if you give 
some users an advantage over other users by raising their priorities, ragged 
performance will result, because the system reacts sharply to even small 
priority differences. 

Never specify a value over 31 (system operation will be unpredictable). 


6.3 Assigning Privileges 

Privileges restrict the performance of certain system activities to certain 
users. These restrictions protect the integrity of the operating system's 
performance and thus the integrity of service provided to users. You should 
grant privileges to each user on the basis of two factors: 

• Whether the user has the skill and experience to use the privilege without 
disrupting the system 

• Whether the user has a legitimate need for the privilege 

Privileges fall into seven categories according to the damage that the user 
possessing them could cause the system: 

• None—No privileges 

• Normal—Minimum privileges to use the system effectively 

• Group—Potential to interfere with members of the same group 

• Devour—Potential to consume noncritical systemwide resources 

• System—Potential to interfere with normal system operation 

• Files—Potential to compromise file security 

• All—Potential to control the system 

A user cannot execute an image that requires a privilege he or she does not 
possess, unless the image is installed as a known image with the privilege 
in question. (See Section 8 for instructions on installing known images.) 
Execution of a known image with temporary privileges (for the duration of 
the image's execution) grants those privileges to the user process executing 
the image. Thus, you should install user images with amplified privileges 
only after ensuring that the user needs the access and is unlikely to misuse it. 
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A user's privileges are recorded in the user's UAF record in a 64-bit privilege 
vector. When a user logs in to the system, the user's privilege vector is 
stored in the header of the user's process. In this way, the user's privileges 
are passed on to the process created for the user. Users can use the DCL 
command SET PROCESS/PRIVILEGES to enable and disable privileges for 
which they are authorized, to further control the privileges available to the 
images they run. Moreover, any user with the SETPRV privilege can enable 
any privilege. 

Table 6-2 lists the privileges by category and gives brief, general definitions of 
them. The following sections describe each privilege in detail in alphabetical 
order and indicate privilege categories. 

Table 6-2 VAX/VMS Privileges by Category, with Definitions 


Category 

Privilege 

Activity Permitted 

None 

None 

None requiring privileges 

Normal 

MOUNT 

Execute mount volume QIO 


NETMBX 

Create network connections 


TMPMBX 

Create temporary mailbox 

Group 

GROUP 

Control processes in the same group 


GRPPRV 

Group access via SYSTEM protection field 

Devour 

ACNT 

Disable accounting 


ALLSPOOL 

Allocate spooled devices 


BUGCHK 

Make bugcheck error log entries 


EXQUOTA 

Exceed disk quotas 


GRPNAM 

Insert group logical names in the name table 


PRMCEB 

Create/delete permanent common event flag 
clusters 


PRMGBL 

Create permanent global sections 


PRMMBX 

Create permanent mailboxes 


SHMEM 

Create/delete structures in shared memory 

System 

ALTPRI 

Set base priority higher than allotment 


OPER 

Perform operator functions 


PSWAPM 

Change process swap mode 


SHARE 

Access devices allocated to other users 


SYSLCK 

Lock systemwide resources 


WORLD 

Control any process 

Files 

DIAGNOSE 

Diagnose devices 


SYSGBL 

Create systemwide global sections 


VOLPRO 

Override volume protection 

All 

BYPASS 

Disregard protection 


CMEXEC 

Change to executive mode 


CMKRNL 

Change to kernel mode 
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Table 6-2 (Cont.) VAX/VMS Privileges by Category/ with 
Definitions 


Category Privilege 

Activity Permitted 

DETACH 

Create detached processes of arbitrary UIC 

LOG—IO 

Issue logical I/O requests 

PFNMAP 

Map to specific physical pages 

PHY_IO 

Issue physical I/O requests 

READALL 

Possess read access to everything 

SECURITY 

Perform security-related functions 

SETPRV 

Enable any privilege 

SYSNAM 

Insert/delete system logical names in the name table 

SYSPRV 

Access objects via SYSTEM protection field 


6.3.1 ACNT Privilege (Devour) 

The ACNT privilege allows a user to create subprocesses or detached 
processes in which accounting is disabled. Thus, only such a privileged user 
can issue the DCL command RUN with the /NOACCOUNTING qualifier or 
inhibit accounting in the Create Process ($CREPRC) system service. 


6.3.2 ALLSPOOL Privilege (Devour) 

The ALLSPOOL privilege allows the user's process to allocate a spooled 
device by executing the Allocate Device ($ALLOC) system service. This 
service lets a process allocate, or reserve, a device for its exclusive use. A 
shareable mounted device cannot be allocated. The user may also allocate a 
spooled device by using the DCL command ALLOCATE. 

You should grant this privilege only to users who need to perform logical 
or physical I/O operations to a spooled device. Ordinarily, the privilege of 
allocating a spooled device is granted only to symbionts (see Section 9.7.11). 


6.3.3 ALTPRI Privilege (System) 

The ALTPRI privilege allows the user's process to 

• Increase its own base priority 

• Set the base priority of another process to a value higher than that of the 
target process 

The base priority is increased by executing the Set Priority ($SETPRI) system 
service or the DCL command SET PROCESS/PRIORITY. As a rule, this 
system service lets a process set its own base priority or the base priority 
of another process. However, one process can set the priority of a second 
process if 

• The process calling the $SETPRI system service has the same UIC as the 
target process 
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• The calling process has process control privilege (GROUP or WORLD) 
over the target process 

With ALTPRI, a process can create a process with a priority higher than its 
own. It creates such a process by using an optional argument to the Create 
Process ($CREPRC) system service or to the DCL command RUN. 

You should not grant this privilege widely; if unqualified users have the 
unrestricted ability to set base priorities, the fair and orderly scheduling of 
processes for execution can easily be disrupted. 


6.3.4 BUGCHK Privilege (Devour) 

Use of the BUGCHK privilege should be restricted to system software 
supplied by DIGITAL that uses the VAX/VMS Bugcheck Facility. This 
privilege allows the user process to make bugcheck error log entries. 


6.3.5 BYPASS Privilege (All) 

The BYPASS privilege allows the user's process read, write, execute, and 
delete access to all files, bypassing UIC protection. 

You should grant this privilege with extreme caution, as it overrides all file 
protection. It should be reserved for experienced users, well-tested, reliable 
programs and command procedures, or the system backup operation (see 
Section 2 and the Guide to VAX/VMS Disk and Magnetic Tape Operations for a 
discussion of backup operations). SYSPRV is adequate for interactive use, as 
it ultimately grants access to all files, while still providing access checks. 


6.3.6 CMEXEC Privilege (All) 

The CMEXEC privilege allows the user's process to execute the Change Mode 
to Executive ($CMEXEC) system service. 

This system service lets a process change its access mode to executive, execute 
a specified routine, and then return to the access mode that was in effect 
before the system service was called. While in executive mode, the process is 
allowed to execute the Change Mode to Kernel ($CMKRNL) system service. 

You should grant this privilege only to users who need to gain access to 
protected and sensitive data structures and internal functions of the operating 
system. If unqualified users have unrestricted access to sensitive data 
structures and functions, the operating system and service to other users 
can easily be disrupted. Such disruptions can include failure of the system, 
destruction of the database, and exposure of confidential information to 
unauthorized persons. 
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6.3.7 CMKRNL Privilege (All) 

The CMKRNL privilege allows the user's process to execute the Change Mode 
to Kernel ($CMKRNL) system service. 

This system service lets a process change its access mode to kernel, execute a 
specified routine, and then return to the access mode that was in effect before 
the system service was called. 

In granting this privilege, follow the guidelines for the CMEXEC privilege. 


6.3.8 DETACH Privilege (All) 

The DETACH privilege allows the user's process to create detached processes 
by executing the Create Process ($CREPRC) system service. Detached 
processes remain in existence even after the user who created them has 
logged off the system. 

An example of a detached process is the process created by the system for a 
user when the user logs in to the system. 

There is no restriction on the UIC that can be specified for a detached process. 
Thus, there are no restrictions on the files and directories to which a detached 
process can gain access. 


6.3.9 DIAGNOSE Privilege (Files) 

The DIAGNOSE privilege allows the user to run online diagnostic programs 
and to intercept and copy all messages that are written to the error log file. 


6.3.10 EXQUOTA Privilege (Devour) 

The EXQUOTA privilege allows the space taken by the user's files on given 
disk volumes to exceed any usage quotas set for the user (as determined by 
UIC) on those volumes. 


6.3.11 GROUP Privilege (Group) 

The GROUP privilege allows the user's process to affect other processes in its 
own group by executing the following process control system services: 

• Cancel Wakeup ($CANWAK) 

• Delete Process ($DELPRC) 

• Force Exit ($FORCEX) 

• Resume Process ($RESUME) 

• Schedule Wakeup (SSCHDWK) 

• Set Priority ($SETPRI) 

• Suspend Process ($SUSPND) 

• Wake ($WAKE) 
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The user's process is also allowed to examine other processes in its own group 
by executing the Get Job/Process Information ($GETJPI) system service. A 
user with the GROUP privilege can issue the SET PROCESS command for 
other processes in its group. 

The GROUP privilege is not needed for a process to exercise control over, or 
to examine, subprocesses that it created. You should grant this privilege to 
users who need to exercise control over each other's processes and operations. 


6.3.12 GRPNAM Privilege (Devour) 

The GRPNAM privilege allows the user's process to insert names in the 
logical name table of the group to which the process belongs and to delete 
names from that table, using the following logical name system services: 
Create Logical Name ($CRELNM) and Delete Logical Name ($DELLNM). 

In addition, the privileged user can use the DCL commands ASSIGN and 
DEFINE to add names to the group logical name table. The DEASSIGN 
command deletes names from the table, and the /GROUP qualifier of the 
MOUNT command shares volumes among group members. 

This privilege should not be granted to all users of the system because it 
allows a user to create an unlimited number of group logical names. When 
unqualified users have the unrestricted ability to create group logical names, 
excessive use of system dynamic memory can degrade system performance. 

In addition, a user with the GRPNAM privilege can interfere with the 
activities of other users in the same group by creating definitions of commonly 
used logical names, such as SYS$SYSTEM. 


6.3.13 GRPPRV Privilege (Group) 

The GRPPRV privilege allows a process access to files using the files' 
SYSTEM protection field when the process' group matches the group of 
the file owner. It also allows a process to change the protection of files whose 
owner group matches the process' group. 


6.3.14 LOG_IO Privilege (All) 

The LOG_JO privilege allows the user's process to execute the Queue I/O 
Request ($QIO) system service to perform logical-level I/O operations. This 
privilege is also required for certain device control functions, such as setting 
permanent terminal characteristics. 

Usually, user I/O requests are handled indirectly by use of an I/O package, 
such as VAX Record Management Services. However, to increase their control 
over I/O operations and to improve the efficiency of I/O operations, skilled 
users sometimes prefer to handle directly the interface between their process 
and a system I/O driver program. They can do this by executing the Queue 
I/O Request system service; in many instances, the operation called for is a 
logical-level I/O operation. 

You should grant this privilege only to users who need it, because it allows a 
process to access data anywhere on the selected volume without the benefit 
of any file structuring. If this privilege is given to unqualified users who have 
no need for it, the operating system and service to other users can easily be 
disrupted. Such disruptions can include the destruction of information on the 
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system device, the destruction of user data, and the exposure of confidential 
information to unauthorized persons. 


6.3.15 MOUNT Privilege (Normal) 

The MOUNT privilege allows the user's process to execute the mount volume 
QIO function. The use of this function should be restricted to system software 
supplied by DIGITAL. 


6.3.16 NETMBX Privilege (Normal) 

The NETMBX privilege allows the user to perform functions related to a 
DECnet computer network. This privilege is normally granted to general 
users. 


6.3.1 7 OPER Privilege (System) 

The OPER privilege allows use of the operator communication process 
(OPCOM), as follows: 

• To reply to user requests 

• To broadcast messages to all terminals logged in 

• To designate terminals as operators' terminals and specify the types of 
messages to be displayed 

• To initialize and control the operator log file 

In addition, this privilege lets the user set devices spooled, create and control 
both batch and output queues, and initialize and mount public volumes. 

You should grant this privilege only to operators of the system. These 
are the users who respond to the requests of ordinary users, who tend to 
the needs of the system's peripheral devices (mounting reels of tape and 
changing printer forms), and who attend to all the other day-to-day chores of 
system operation. (A nonprivileged user can log in on the console terminal to 
respond to operator requests, for example, to mount a tape.) 


6.3.18 PFNMAP Privilege (All) 

The PFNMAP privilege allows the user's process to map to specific pages of 
physical memory or I/O device registers, no matter who is using the pages or 
registers. 

You should exercise caution in granting this privilege. If unqualified users 
have unrestricted access to physical memory, the operating system and 
service to other users can easily be disrupted. Such disruptions can include 
failure of the system, destruction of the database, and exposure of confidential 
information to unauthorized persons. 
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6.3.19 PHYSIO Privilege (All) 

The PHY—IO privilege allows the user's process to execute the Queue I/O 
Request ($QIO) system service to perform physical-level I/O operations. 

Usually, users' I/O requests are handled indirectly by use of an I/O package 
such as VAX Record Management Services. However, to increase their control 
over I/O operations and to improve the efficiency of their applications, skilled 
users sometimes prefer to handle directly the interface between their process 
and a system I/O driver program. They can do this by executing the Queue 
I/O Request system service; in many instances, the operation called for is a 
physical-level I/O operation. 

You should grant the PHY_IO privilege only to users who need it; in fact, this 
privilege should be granted even more carefully than the LOG-JO privilege 
(see Section 6.3.14). If this privilege is given to unqualified users who have 
no need for it, the operating system and service to other users can easily be 
disrupted. Such disruptions can include the destruction of information on the 
system device, the destruction of user data, and the exposure of confidential 
information to unauthorized persons. 


6.3.20 PRMCEB Privilege (Devour) 

The PRMCEB privilege allows the user's process to create or delete a 
permanent common event flag cluster by executing the Associate Common 
Event Flag Cluster ($ASCEFC) or Delete Common Event Flag Cluster 
($DLCEFC) system service. Common event flag clusters enable cooperating 
processes to communicate with each other, thus providing the means of 
synchronizing their execution. 

This privilege should not be granted to all users of the system, because it 
allows the user to create an unlimited number of permanent common event 
flag clusters. A permanent cluster remains in the system even after the 
creating process has been terminated and continues to use up a portion of 
system dynamic memory. When many users have the unrestricted ability to 
create permanent common event flag clusters, the excessive use of system 
dynamic memory can degrade system performance. 


6.3.21 PRMGBL Privilege (Devour) 

The PRMGBL privilege allows the user's process to create global sections 
by executing the Create and Map Section ($CRMPSC) system service. 

In addition, the user with this privilege (plus the CMKRNL and SYSGBL 
privileges) can use the Install Utility. 

Global sections are shared structures that can be mapped simultaneously in 
the virtual address space of many processes. All processes see the same code 
or data. Global sections are used for reentrant subroutines or data buffers. 

You should grant this privilege with care. If permanent global sections are 
not explicitly deleted, they tie up space in the global section and global page 
tables, which are limited resources. 
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6.3.22 PRMMBX Privilege (Devour) 

The PRMMBX privilege allows the user's process to create or delete a 
permanent mailbox by executing the Create Mailbox and Assign Channel 
($CREMBX) system service or the Delete Mailbox ($DELMBX) system service. 

Mailboxes are buffers in virtual memory that are treated as if they were 
record-oriented I/O devices. A mailbox is used for general interprocess 
communication. 

The PRMMBX privilege should not be granted to all users of the system. 
Permanent mailboxes are not automatically deleted when the creating 
processes are deleted and, thus, continue to use up a portion of system 
dynamic memory. 


6.3.23 PSWAPM Privilege (System) 

The PSWAPM privilege allows the user's process to control whether it can 
be swapped out of the balance set by executing the Set Process Swap Mode 
($SETSWM) system service. Not only must a process have this privilege to 
lock itself in the balance set (that is, to disable swapping), but also to unlock 
itself (that is, to enable swapping). 

With this privilege, a process can create a process that is locked in the balance 
set (process swap mode disabled) by using an optional argument to the Create 
Process ($CREPRC) system service or, when the DCL command RUN is used 
to create a process, by using a qualifier of the RUN command. 

You should grant this privilege only to users who need to lock a process in 
memory for performance reasons. Typically, this will be a real-time process. 
If unqualified users have the unrestricted ability to lock processes in the 
balance set, physical memory can be held unnecessarily, thereby degrading 
system performance. 


6.3.24 READALL Privilege (All) 

The READALL privilege allows the process to bypass existing restrictions that 
would otherwise prevent the process from reading a file. However, unlike 
the BYPASS privilege, which permits writing and deleting, READALL permits 
only reading of the file. 

You should grant this privilege only to individuals with appropriate 
management responsibilities at your site. 


6.3.25 SECURITY Privilege (All) 

The SECURITY privilege allows a process to perform security-related 
functions such as enabling or disabling security audits or setting the system 
password. 

You should grant this privilege only to individuals responsible for system 
security. 
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6.3.26 SETPRV Privilege (All) 

The SETPRV privilege allows the user's process to create processes whose 
privileges are greater than its own, by executing the Create Process 
($CREPRC) system service with an optional argument, or by issuing the 
DCL command RUN to create a process. A user with this privilege can 
also execute the DCL command SET PROCESS/PRIVILEGES to obtain any 
desired privilege. 

You should exercise the same caution in granting the SETPRV privilege as in 
granting any other privilege in the ALL category, since SETPRV allows the 
user to enable any or all privileges. 


6.3.27 SHARE Privilege (System) 

The SHARE privilege allows the user's process to assign channels to devices 
allocated to other users. 

Normally you should grant this privilege only to system software such as 
symbionts. This privilege would allow an irresponsible user to interfere with 
the operation of devices belonging to other users. 


6.3.28 SHMEM Privilege (Devour) 

The SHMEM privilege allows the user's process to create and delete global 
sections and mailboxes (permanent and temporary) in multiport memory, if 
the process also has appropriate PRMGBL, PRMMBX, SYSGBL, and TMPMBX 
privileges. Just as in local memory, the space required for a multiport memory 
temporary mailbox counts against the buffered I/O byte count limit (BYTLM) 
of the process. 


6.3.29 SYSGBL Privilege (Files) 

The SYSGBL privilege allows the user's process to create system global 
sections by executing the Create and Map Section ($CRMPSC) system service. 
In addition, the user with this privilege (plus the CMKRNL and PRMGBL 
privileges) can use the Install Utility. 

You should exercise caution in granting this privilege. System global sections 
require space in the global section and global page tables, which are limited 
resources. 


6.3.30 SYSLCK Privilege (System) 

The SYSLCK privilege allows the user's process to lock systemwide resources 
with the Enqueue Lock Request ($ENQ) system service. You should grant 
this privilege to users who need to run programs that lock resources in the 
systemwide resource name space. You should exercise caution in granting 
this privilege, since users who hold it can interfere with the synchronization 
of system and other users' software. 
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6.3.31 SYSNAM Privilege (All) 

The SYSNAM privilege allows the user's process to insert names in the 
system logical name table and to delete names from that table by using the 
Create Logical Name ($CRELNM) and Delete Logical Name ($DELLNM) 
system services. 

In addition, the user with this privilege can use the DCL commands ASSIGN 
and DEFINE to add names to the system logical name table, and can use the 
DEASSIGN command to delete names from the table. 

You should grant this privilege only to the system operators or to system 
programmers who need to define system logical names (such as names for 
user devices, library directories, and the system directory). For example, 
to mount or dismount a system volume, which entails defining a system 
logical name, you must have the SYSNAM privilege. Note that a user with 
the SYSNAM privilege could redefine such critical system logical names as 
SYS$SYSTEM and SYSUAF, thus gaining control of the system. 


6.3.32 SYSPRV Privilege (All) 

The SYSPRV privilege allows the user to assume the file access rights of a 
system user, and to change the owner UIC and protection of a file. Even if a 
file is protected against SYSTEM access, the user with the SYSPRV privilege 
can simply change the file's protection to gain access to it. 

You should exercise caution in granting this privilege. If unqualified users 
have SYSTEM access rights, the operating system and service to others can 
easily be disrupted. Such disruptions can include failure of the system, 
destruction of the database, and exposure of confidential information to 
unauthorized persons. 


6.3.33 TMPMBX Privilege (Normal) 

The TMPMBX privilege allows the user's process to create a temporary 
mailbox by executing the Create Mailbox and Assign Channel ($CREMBX) 
system service. 

Mailboxes are buffers in virtual memory that are treated as if they were 
record-oriented I/O devices. A mailbox is used for general interprocess 
communication. Unlike a permanent mailbox, which must be explicitly 
deleted, a temporary mailbox is deleted automatically when it is no longer 
referenced by any process. Note that this privilege is required to use the DCL 
commands SUBMIT and PRINT. 

You should usually grant this privilege to all users of the system to facilitate 
interprocess communication. System performance is not likely to be degraded 
by permitting the creation of temporary mailboxes, because their number is 
controlled by limits on the use of system dynamic memory (BYTLM quota). 


6-17 










Resource Control 


6.3.34 VOLPRO Privilege (Files) 

The VOLPRO privilege allows the user to 

• Initialize a previously used volume with an owner UIC different from the 
user's own UIC 

• Override the expiration date on a disk or disk volume he or she does not 
own 

• Mount with the /FOREIGN qualifier a Files-11 volume he or she does not 
own 

• Override the owner UIC protection of a volume 

The VOLPRO privilege permits control only over volumes that the user can 
mount or initialize. Volumes mounted with the /SYSTEM qualifier are safe 
from the user with the VOLPRO privilege as long as the user does not also 
have the SYSNAM privilege. 

You should exercise extreme caution in granting the VOLPRO privilege. If 
unqualified users can override volume protection, the operating system and 
service to others can be disrupted. Such disruptions can include destruction 
of the database and exposure of confidential information to unauthorized 
persons. 


6.3.35 WORLD Privilege (System) 

The WORLD privilege allows the user's process to affect other processes both 
inside and outside its group by executing the following process control system 
services: 

• Cancel Wakeup ($CANWAK) 

• Delete Process ($DELPRC) 

• Force Exit ($FORCEX) 

• Resume Process ($RESUME) 

• Schedule Wakeup ($SCHDWK) 

• Set Priority ($SETPRI) 

• Suspend Process ($SUSPND) 

• Wake ($WAKE) 

The user's process is also allowed to examine processes outside its own group 
by executing the Get Job/Process Information ($GETJPI) system service. The 
user with WORLD privilege can issue the DCL commands SET QUEUE, 
DELETE/ENTRY, STOP/ENTRY, and SET PROCESS for all other processes. 

To exercise control over subprocesses that it created or to examine these 
subprocesses, a process needs no special privilege. To affect or to examine 
other processes inside its own group, a process needs only the GROUP 
privilege. But to affect or examine processes outside its own group, a process 
needs WORLD privilege. You should normally grant this privilege to any 
user who needs to affect other processes on a systemwide basis. 
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6.4 Accounting for the Use of System Resources 

For accounting purposes, the VAX/VMS system keeps records of the use 
of system resources. These records are kept in the accounting log file 
SYS$MANAGER:ACCOUNTNG.DAT. This file is updated whenever 

• The system is initialized. 

• An accountable process or image terminates. 

• A print job is completed. 

• A login failure occurs. 

In addition, users can send messages to be inserted in the accounting log file. 

Privilege is required to suppress the accounting function and thus avoid 
accounting for the use of system resources. Only a user who has the ACNT 
privilege can create subprocesses or detached processes in which accounting 
is disabled. The /NOACCOUNTING qualifier of the DCL command RUN 
disables all accounting in a created process. 

A user with the OPER privilege can selectively disable various kinds of 
accounting throughout the system by using the /DISABLE qualifier of the 
DCL command SET ACCOUNTING. Usually, this action is considered 
a system management task. See the VAX/VMS DCL Dictionary for a full 
description of the SET ACCOUNTING command. 


6.4.1 Accounting Records 

Accounting records contain cumulative accounts of the resources used either 
by processes or images set up for users, or by print symbionts that print 
out files for users. Each accounting record contains three fields—user 
name, UIC, and account name—that identify the user and establish the 
connection between the accounting record and a user of the system. These 
fields correspond to similar fields of the user's account record in the user 
authorization file (UAF). 

As system manager, you can use the Accounting Utility to sort, select, and 
report the accounting records. The reports can provide valuable system 
management tools. (See the VAX/VMS Accounting Utility Reference Manual.) 
Alternatively, by using the detailed accounting records provided by the 
system, you or perhaps a system programmer can devise programs for 
reporting on the use of system resources and for billing for their use. 


6.4.2 Accounting Log File 

The accounting log file is created and opened automatically when 
the operating system is initialized. Accounting records are arranged 
chronologically in this file. The following list summarizes the characteristics 
of the accounting log file: 

• File name: ACCOUNTNG.DAT (this file is not an ASCII file; hence, it 
must be formatted before it is printed) 

• Residence and directory: SYS$MANAGER 

• File organization: sequential 
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• Record length: variable 

• Record types: eight 

The eight types of records correspond to the conditions that cause records to 
be written to the file. These record types are shown in the list that follows. 
Note that their corresponding codes, as defined in the macro $ACRDEF in 
SYS$LIBRARY:STARLET.MLB, are shown in parentheses: 

• Records written when processes are deleted (ACR$K_PRCDEL) 

• Records written when an image terminates (ACR$K_IMGDEL) 

• Records written when the system was initialized (ACR$K_SYSINIT) 

• Records written when print jobs are queued (ACR$K_PRINT) 

• Records written when login failures occurred (ACR$K_LOGFAIL) 

• Records written when users' messages are sent to the accounting log file 
(ACR$K_USER) 

• Records that point to the next accounting file (ACR$K_FILE_FL) 

• Records that point to the previous accounting file, if any 
(ACR$K —FILE _BL) 

For more information about the records of the accounting log file, see the 
VAX/VMS Accounting Utility Reference Manual. 

As records are entered in the accounting log file, all but image termination 
records are immediately flushed to disk. This precaution guarantees the 
integrity of the file and the completeness of accounting data even if the 
system fails. 

Normally, the current version of the accounting log file is closed at the end 
of a billing period, and a new version is created and opened. As a rule, you 
perform this job with the SET ACCOUNTING command. 

If an attempt to write to the accounting log file results in an error, the file is 
closed automatically and a new copy is created and opened. 
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Maintaining Public Files and Volumes 


This chapter contains guidelines for setting up and maintaining public 
files and volumes. It describes routine setup tasks such as initializing and 
mounting public volumes. It also describes how to maintain volume integrity 
(BACKUP) and manage disk space. 

Public volumes, also called system volumes, are file-structured disk volumes 
that contain public files. Such files must be available to most, if not all, users. 
Public volumes can also contain files that users create for their own private 
use or for general use. Thus, as long as UlC-based file protection permits it, 
all users have access to public volumes and to the files on them. 

Public volumes can contain the following kinds of public files supplied by 
DIGITAL: 

• The operating system itself in executable form, and files related to the 
operating system 

• Utility programs in executable form 

• Diagnostic and test programs in executable form, and files related to these 
programs 

• Various system libraries such as macro libraries, object module libraries, 
shared run-time libraries, and error message libraries 

• Text files such as help files 

• Optional software in executable form, plus related libraries and other files 

In addition, you can include on public volumes files that are unique to an 
installation, which must be accessible to many or all users. 

Finally, you can permit any user to create and store files on a public volume. 
As a rule, you create a default disk file directory on a public volume for each 
user authorized to use the system (see Section 5). Depending on their file 
protection, user files may be of general or restricted accessibility. Such use 
of a public volume, however, is subject to limitation: a user is free to create, 
write, and manipulate files on a public volume only if volume protection 
permits, if the user has write access to a directory on the volume, and if disk 
quota permits. 


7.1 Setting Up Public File Structures 

A major duty in system management is maintaining public file structures. 
You must strike a balance between your users' needs and the system's 
available mass storage resources. You must determine how mass storage 
devices on your system will be configured, which devices will hold public 
system volumes, which devices will be available for users' private volumes, 
and how the public volumes will be configured. You are also responsible for 
creating top-level user file directories as needed, and monitoring users' disk 
space usage. 
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7.1.1 Storing User Files 

In most circumstances, you will want to dedicate most of your large disk 
drives to public disk storage. In relatively large system configurations, you 
should not put user files on the system volume. The system disk will be kept 
active with paging and swapping, spooling files, maintaining system logs, 
and so forth. Secondary paging and swapping files can be placed on other 
devices to balance disk activity load (see the SYSGEN commands CREATE 
and INSTALL in the VAX/VMS System Generation Utility Reference Manual for 
more information. Furthermore, if you ever find it necessary to build a new 
system disk from scratch, you will find that having user files on it makes the 
process much more difficult and time-consuming. 

If you have a relatively small mass storage configuration, you will have no 
other choice than to allocate user files on the system volume. Under these 
circumstances, you should take precautions with disk quotas and to ensure 
that users' files do not exhaust the free space on the system disk. Note that 
issuing the command SET DIRECTORY /VERSION _LIMIT=n is one way to 
control the amount of disk space consumed. 


7.1.2 Using Volume Sets 

A volume set is a collection of disk volumes that have been bound into a 
single entity, by the DCL command MOUNT/BIND. A volume set looks like 
a single, large volume. Files are automatically allocated anywhere on the 
volume set that space is available, disk quotas are enforced over the entire 
set, and a single directory structure covers the whole volume set. If you want 
to provide a large homogeneous public file space, use a volume set. 

If you intend to create database files that are larger than any single disk 
volume, you must use a volume set. It is worth noting that the file system 
attempts to balance the load on the volume set, with tactics such as creating 
new files on the volume that is the least full at the time. 

On the other hand, if you want several distinct areas of file storage, with 
different user bases or different management policies, you must use a separate 
volume (or volume set) for each area. For example, you might want one 
volume for permanent user storage, with carefully limited quotas and careful 
backups; and another volume for "scratch" use, which has liberal or no 
quotas, is not backed up, and whose files are cleaned out on a periodic 
basis. Each separate volume or volume set must contain a top-level user file 
directory for each user who will keep files on that volume. 

An advantage of using separate volumes is their modularity. Should one of 
the drives holding a volume set be out of service, the whole volume set will 
be unavailable because of the interconnected nature of its directory structure. 
When a drive holding a single volume is not functioning, only a well-defined 
set of files becomes unavailable. 

For planning purposes, keep in mind the following: 

• Any single volume can be turned into a volume set by binding it with a 
newly initialized volume. Likewise, you can always add another newly 
initialized volume to an existing volume set. 

• You can bind disk volumes of different types into the same volume set. 

• You cannot bind two existing separate volumes containing files into a 
volume set. (The MOUNT command appears to let you do this, but the 
result will not be a coherent volume set.) 
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• You issue the MOUNT/BIND command only once to effect binding; 
thereafter, the volume-set association is recorded on the volumes. (See the 
VAX/VMS Mount Utility Reference Manual for more information.) 

• Once you have bound two or more volumes into a volume set, they 
cannot be separated. The only way to separate a volume set is to 
selectively copy sets of directories using the Backup Utility (BACKUP). 
(See the VAX/VMS Backup Utility Reference Manual for more information.) 


Caution: DIGITAL recommends that you not make the system disk part of a 

volume set. While the VAX/VMS system will continue to boot and run 
successfully if you do this, optional product installations, maintenance 
updates, and system upgrades will not install correctly on a system 
disk that is part of a volume set. Once you have installed an update or 
software product, system files can be allocated anywhere on the volume 
set, and VAX/VMS will no longer boot successfully. 


7.2 Formatting Disks 

Disks that you purchase from DIGITAL are pre-formatted with a field service 
diagnostic utility program. However, under some circumstances you may 
need or want to format a disk. Disks must be reformatted if they have 
been exposed to X-rays, degaussing, or certain kinds of power disruptions. 
Also, you may find formatting desirable if you are experiencing excessive 
parity errors on a disk. In such cases, you should contact your Field Service 
representative for assistance. 


7.3 Initializing Public Volumes 

The purpose of initializing a disk volume is to delete all old information 
from the volume and to impart to the volume a Files-11 structure that the 
operating system recognizes. This structure prepares a volume to receive data 
and stores it so that the operating system can locate it easily. 

When initializing a public volume, you must specify the /SYSTEM qualifier 
with the DCL command INITIALIZE. You may also need to use one or more 
of the following INITIALIZE qualifiers when initializing a public volume: 

• /ACCESSED=n 

• /CLUSTER_SIZE=n 

• /EXTENSIONS 

• /HEADERSs 

• /INDEX=position 

• /MAXIMUM _FILESs 

• /WINDOWS 

As described below, selecting appropriate values for n and selecting the 
appropriate position for the index file often involve making tradeoffs. The 
following guidelines for initializing public volumes supplement information 
presented in the VAX/VMS DCL Dictionary. 
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/ACCESSED Qualifier 

The /ACCESSED qualifier provides an estimate of the number of directories 
expected to be in use concurrently on a volume. The file system keeps this 
number of directory file control blocks in system space for ready access 
depending on which directories were most recently used. The result is 
a substantial reduction of overhead in directory operations. For volumes 
mounted with the /SYSTEM qualifier, the SYSGEN parameter ACP_ 
DINDXCACHE overrides this value. 

When you create a volume set, specify reasonable values for the /ACCESSED 
qualifier on each volume, because the total number of directory file control 
blocks retained will be the sum of the values of all the /ACCESSED qualifiers 
specified for the volume set. 

/CLUSTER-SIZE Qualifier 

The /CLUSTER-SIZE qualifier specifies the fundamental unit of allocation 
(expressed in blocks) on a volume. In selecting the cluster size, you trade off 
wasted space at the ends of files against the size of the volume storage bit 
map, which must contain one bit for each cluster on the volume (or one block 
for each 4096 clusters). 

/HEADERS Qualifier 

The /HEADERS qualifier specifies the number of file headers to be allocated 
initially to the index file. The primary advantage of preallocating file headers 
is that they will then be located near the storage map file (usually in the 
middle of the disk). This placement of file headers helps reduce head motion 
during file manipulation. This value should be estimated conservatively, 
because space allocated to headers cannot later be made available for file 
storage. However, an overly conservative estimation of file-header space can 
also cause excessive disk-head motion. 

/INDEX Qualifier 

The /INDEX qualifier specifies the location of the index file on a volume. 

The default position (MIDDLE) results in minimum head motion during file 
processing. The position BEGINNING should be used if the disk is to contain 
only one or a few very large contiguous files. 

When the Backup Utility copies a volume as the result of a BACKUP/IMAGE 
command, it preserves the placement of the index file, if the output device is 
the same type. Otherwise, it defaults to MIDDLE. 

/MAXIMUM—FILES Qualifier 

The /MAXIMUM—FILES qualifier specifies the maximum number of files that 
a volume can contain. The default value is fairly liberal. A closer estimate of 
it helps optimize the dynamic allocation of the index file; once set, however, 
the maximum number of files for a volume cannot be increased. Note that 
each directory and each extension header of a multiheader file counts as a file 
against this maximum value. 

/WINDOW Qualifier 

The /WINDOW qualifier specifies the default number of map pointers in a 
file access window. This value is the number of extents of a file to which 
access can be gained without the cost of file system intervention. 
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7.4 



Mounting Public Volumes 

The purpose of mounting a volume or volume set is to establish a relationship 
between the volume or volume set, the device on which the volume is 
physically mounted, and one or more processes that can gain access to the 
volume. 

In mounting a public volume (by using the /SYSTEM qualifier to the DCL 
command MOUNT), you may need to use one or more of the qualifiers 
/ACCESSED, /EXTENSION, and /WINDOW (described in Section 7.3), or 
the following additional qualifiers: 

• /[NO]ASSIST 

• /COMMENT=text 

• /[NO]MOUNT_ VERIFICATION 

• /CLUSTER 

The following guidelines supplement information presented in the VAX/VMS 
DCL Dictionary. 

/[NO]ASSIST Qualifier 

The /[NOJASSIST qualifier enables or disables the operator-assisted mount 
feature. By default, this feature is enabled. You should encourage your users 
to take advantage of this feature, which repeatedly alerts the operator of your 
request until the request is satisfied. 

There is a situation where operator-assisted mounts generally prove 
undesirable. During the execution of SYSTARTUP.COM, operator-assisted 
mounts are disabled by default. The reason is that the absence of some 
system volume normally mounted during SYSTARTUP.COM could prevent 
the system from booting. 

If you have one or more volumes that must be present for the correct 
operation of your system, you can specify the /ASSIST qualifier in the 
commands to mount them; be prepared for the following consequences, 
however, if any volume proves to be offline or unavailable. 

• The operator assistance software will issue an operator request to have the 
volume made ready, and will wait for its completion. There is no problem 
if you can ready the volume. 

• If you cannot ready the volume (perhaps the drive is down or the volume 
is corrupted), you cannot complete SYSTARTUP.COM. To abort the 
mount request, you would have to issue a REPLY/ABORT operator 
command. However, the system console is running SYSTARTUP.COM 
and is unavailable. Furthermore, the other system terminals are usually 
not yet properly configured or logins are not yet enabled. 

Under these circumstances, reboot the system using a conversational 
bootstrap procedure, and enter the following command at the SYSBOOT> 
prompt: 

SYSBOOT> SET STARTUP.Pl "MIN" 

This command initiates a minimum startup procedure as described in 
Section 4. 
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/COMMENT Qualifier 

The /COMMENT qualifier includes a quoted text string that you specify 
as part of the mount request. This qualifier is primarily useful in situations 
where operator assistance is expected, for it passes on information such as 
the physical location of a particular volume that is required. You should 
encourage your users to take advantage of this feature. 

/[NO]MOUNT_VERIFICATION Qualifier 

The /[NO]MOUNT_VERIFICATION qualifier enables or disables the mount 
verification feature on Files-11 disks. By default, the mount verification 
feature is enabled. If a device goes offline, mount verification will not abort 
requests, but instead will retain pending requests in a queue. However, note 
that this feature has no effect on foreign disks or magnetic tapes. This feature 
is explained in Section 7.6. 

/CLUSTER Qualifier 

The /CLUSTER qualifier specifies that after the volume is successfully 
mounted on the local node, or if it is already mounted /SYSTEM on the local 
node, it is to be mounted on every other node in the existing VAXcluster. See 
the Guide to VAXclusters for more information on mounting clusterwide disk 
volumes. 

Note: You can monitor Files-11 ACP performance with the MONITOR FCP 
command of the Monitor Utility. (See the VAX/VMS Monitor Utility 
Reference Manual.) The information MONITOR provides can help you 
determine how to configure your file system. 


7.4.1 Preparing Disk and Magnetic Tape Volumes 

Users may prepare their own volumes for use. Or, depending on the physical 
arrangement of the installation and the type of volume to be accessed, you or 
an operator may be called upon to assist them. (In most cases, an operator 
performs the tasks described in this section and Section 7.4.2.) The following 
are some of the reasons why users may require assistance: 

• The processor and its peripheral devices are off limits to or remotely 
located from some or all users. 

• The magnetic tape system has requested that a tape volume be mounted. 

• A system or public disk needs to be mounted by the operator or system 
manager, because most users do not have sufficient privileges. 

Users normally communicate with an operator to gain access to volumes, and 
the operator performs one or more of the following tasks: 

• Physically mounts the volume on the device. Physically mounting a 
volume means placing it on a specific drive and starting the drive. For 
tape drives, the operator loads the tape into the drive and then presses the 
LOAD button to start the drive. For disk drives, the operator places the 
disk in the disk drive and then presses the START or RUN button to start 
the drive. 
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If it is not necessary to initialize the disk, users can issue a single MOUNT 
command to allocate the device and request assistance as necessary. For 
example, a user might enter the DCL command MOUNT to issue the mount 
request; or MOUNT/COMMENT to also send to the operator's terminal 
a message specifying the name of the device allocated, the volume to be 
mounted, the physical identification on the outside of the volume, and 
its location. (For a complete description of the MOUNT command and 
qualifiers, refer to the description of the Mount Utility (MOUNT) in the 
VAX/VMS Mount Utility Reference Manual.) The user then waits until the 
system responds with a message indicating that the volume is mounted. 

Examples of allocating devices and initializing and mounting volumes 
are provided in the VAX/VMS DCL Dictionary under the ALLOCATE, 
INITIALIZE, and MOUNT commands. 

For more information on handling magnetic tape volumes, see the Guide to 
VAX/VMS Disk and Magnetic Tape Operations. You should also consult that 
manual for information on requests and notifications concerning the mounting 
and dismounting of disk and magnetic tape volumes. 


7.4.2 Responding to Mount Requests from Users 

When a user requests that a specific disk or magnetic tape be mounted 
on a device, the following message format is displayed by the operator 
communication process (OPCOM) on the operator terminal: 

xmxxmxx OPCOM, dd: mmm: y y y y: hh: mm: s s : c c yX/X/X/X/M 
request 'request-ia,' from user 'USERNAME' 

For example, a user requesting that the volume TEST-FILES be mounted on 
the device DMA2: could issue the following command: 

$ MOUNT DMA2: TEST_FILES/COMMENT="Shelf slot 6B" 

This command notifies the operator by displaying at the operator terminal a 
message similar to the following: 

yx/x/x/xm OPCOM, 15-APR-19S6 15:47:50.26 
request 5, from user MALCOLM 

Please mount volume TEST.FILES in aevice _DMA2: 

Shelf slot 6B 

The user receives a message indicating that the operator has received the 
request: 

'/.MOUNT-I-OPRQST, Please mount volume TEST.FILES in aevice _DMA2: 

Shelf slot 6B 

Besides requesting a specific device for mounting a volume, the user can make 
a generic MOUNT request by specifying a device type. To mount the volume 
CITIES on a magnetic tape drive whose name begins with MT, for example, 
the user would issue the following command: 

$ MOUNT MT: CITIES/COMMENT="Slot 12c" 

If the user has already allocated a drive whose name begins with MT, the 
Mount Utility will request that CITIES be mounted on that particular drive. 

If the user has not allocated a drive whose name begins with MT, the utility 
will allocate the first available TE16, TU45, or TU77 tape drive it finds, and 
issue a request to mount CITIES on that drive. 
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To respond to user requests for mounting volumes, the operator proceeds as 
follows: 

1 Places the volume on the specified device. After the operator has located 
the physical volume and placed it on the device, the user receives 
messages similar to the following: 

•/.MOUNT-1-MOUNTED, TEST.FILES mounted on _DMA2: 

AMOUNT-I-RQSTDON, operator request canceled. 

2 Performs the necessary startup procedure. On disk drives, the startup 
procedure requires pressing the START or RUN button; on magnetic tape 
drives, it requires pressing the LOAD button. 

If the user intends to write to a magnetic tape volume to be mounted, the 
operator verifies that the magnetic tape contains a write ring before loading 
the volume on the drive. A volume that does not contain a write ring is 
write-locked and thus cannot be accessed for write operations. 

If the user wants a particular disk to be checked for bad blocks, the operator 
verifies that the volume has been mounted with the /FOREIGN qualifier. For 
information on how to invoke and use the Bad Block Locator Utility (BAD), 
see the VAX/VMS Bad Block Locator Utility Reference Manual. 

For more information on the user's role in mounting volumes, see the Guide 
to VAX/VMS Disk and Magnetic Tape Operations. 


7.5 Maintaining Volume Integrity 

To enhance performance, the system caches in memory information 
concerning a volume's free space, file identifications, quota file entries, and 
file headers. You determine the degree of caching with the ACP cache system 
parameters (see the discussion of SYSGEN in the VAX/VMS System Generation 
Utility Reference Manual). Individual users can alter cache sizes on their 
volumes with qualifiers of the DCL command MOUNT (see the VAX/VMS 
DCL Dictionary). The system writes the information in the caches to the disk 
when the disk is dismounted or the system is shut down. Naturally, removal 
of a disk before the caches are written back loses any changes made to the 
information in the caches. Therefore, neither you nor the individual user 
should 

• Write lock a volume while it is mounted 

• Remove a volume from a drive until it has been dismounted 

• Halt the system without performing an orderly shutdown procedure (see 
Section 4) 

If anyone write locks a volume at mount time, the system additionally applies 
a software write lock. If you need to write enable a volume that was mounted 
while the WRITE LOCK switch was on, you must first dismount the volume, 
then write enable the drive, and then remount the volume. If a volume was 
mounted on a drive with write lock off and then someone toggles the WRITE 
LOCK switch on (and if mount verification is enabled for the volume, which 
it is by default), the volume enters mount verification. All I/O operations to 
the volume are suspended. Section 7.6.2 describes how recovery is effected 
with write-lock mount verification. (Without the mount verification facility, 
you would have to dismount the volume, write enable the drive, and then 
remount the volume.) 
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At mount time, if the system detects that the caches were not written back 
the last time the volume was used, the system automatically rebuilds the file 
information by scanning the contents of the volume. However, file headers 
for files open at the time of the improper dismount may be partially or wholly 
lost. 


7.6 Mount Verification 

The mount verification feature of Files-11 disk handling generally leaves 
users unaware that a mounted disk has gone off line and returned on line 
or in some other way has become unreachable and then restored. Mount 
verification is enabled by default with the /MOUNT—VERIFICATION 
qualifier when the disk is mounted. To disable mount verification, the user 
must specify /NOMOUNT—VERIFICATION when mounting the disk. Note 
that this feature does not apply to foreign disks or to magnetic tapes. 

Mount verification sends messages to OPCOM. Because there are cases 
where mount verification messages are needed at the operator's console and 
OPCOM might not be able to provide them, mount verification also sends 
special messages with the prefix %SYSTEM-I-MOUNTVER to the operator's 
console only, that is, to OP AO. For example, if the system disk undergoes 
a mount verification or if OPCOM is not present on a system, the operator 
would at least receive the messages with the %SYSTEM-I-MOUNTVER 
prefix. Under normal circumstances, both messages are received at the 
operator's terminal, with the %SYSTEM-I-MOUNTVER message arriving 
first. 


7.6.1 Device Offline Mount Verification 

Mount verification is initiated under the following conditions: 

• A disk volume is taken off line (for example, it might be spun down) 
because of a hardware or user error. Most disk drives generate a special 
interrupt when the volume comes back on line, which causes the software 
to mark the volume as invalid. However, some disk drives (such as the 
RX01, RX02, RL02) do not generate online attention interrupts. For these 
devices, an offline condition is only detected when an I/O operation is 
initiated for the drive. 

• An I/O operation fails with a medium offline or volume invalid status. 
The software marks the volume to indicate that it is undergoing mount 
verification, and all I/O operations to the disk are stalled. 

OPCOM then issues a message to the operators enabled for DISKS and 

DEVICES to announce the disk's unavailability, in the following format: 

nmnun OPCOM. dd-mmm-yyyy hh:mm: ss .cc 

Device 'device-name' is offline. 

Mount verification in progress. 

If a mounted disk volume goes offline while mount verification is enabled, 

you can act as follows to resume operations: 

1 Take the disk out of the offline and verification pending state by shutting 
down mount verification with one of the three techniques described 
in Section 7.6.3. These techniques cause any pending or future I/O 
operations to the volume to fail. 
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2 If the disk drive is faulty, but another functioning drive is available on the 
same controller, you can move the disk to the functioning drive and swap 
the unit select plugs. 

When the disk comes back on line, and is detected by the mount verification 
software that polls the disk drive, the system verifies that the disk's home 
block matches the one in the database of mounted volumes, thus confirming 
that this is the same disk as previously mounted. 

If the drive contains the wrong volume, OPCOM issues a message in the 
following format: 

XXXXXXXXXXX OPCOM, dd-mmin-yyyy hh:mm:ss.cc XXXXXXXXXXX 
Device 'device-name' contains the wrong volume. 

Mount verification in progress. 

After the mount verification succeeds, the disk is marked as valid. OPCOM 
issues the following message: 

XXXXXXXXXXX OPCOM, dd-mmm-yyyy hh:mm:ss.cc XXXXXXXXXXX 

Mount verification completed for device 'device-name.' 

At this point I/O operations to the disk are allowed to proceed, as shown in 
the following example: 

XXXXXXXXXXX OPCOM, 15-APR-i986 11:54:54.12 XXXXXXXXXXX 
Device DMAO: is offline. 

Mount verification in progress. 

XXXXXXXXXXX OPCOM. lS-APR-lQSe 11:57:34.22 XXXXXXXXXXX 
Mount verification completed for device DMAO:. 

In this example, the message from OPCOM informs the operator that device 
DMAO has gone offline and mount verification has been initiated. The 
operator finds that the drive was accidentally spun down and successfully 
spins it back up. The next message indicates that mount verification is 
satisfied that the same volume is on the drive (which it has found is on line 
again), and all I/O operations to the volume resume. 


7.6.2 Device Write-Lock Mount Verification 

Devices may become write locked under the following conditions: 

• A hardware or user error occurs while a Files-11 disk volume is mounted 
for writing (the /WRITE qualifier is the default). 

• The software discovers that the disk is write locked (typically an I/O fails 
with a write-lock error). The disk is marked that verification is in progress. 

OPCOM issues a message to the operators enabled for DISKS and DEVICES 

to announce the disk's unavailability: 

XXXXXXXXXXXX OPCOM. dd-mmm-yyyy hh:mm:ss.cc %%%%%%%%%%% 

Device 'device-name' has been write locked. 

Mount verification in progress. 

If for some reason a mounted disk volume becomes write locked while mount 

verification is enabled, you can act as follows to resume operations: 

1 Take the disk out of the verification pending state by shutting down 
mount verification with one of the techniques described in Section 7.6.3. 
These techniques cause the pending and future I/O operations to the 
volume to fail. 
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2 Enable the drive for writing by toggling the drive's hardware WRITE 
LOCK switch. 

3 If the disk drive is faulty, but another functioning drive is available on the 
same controller, you can move the disk to the functioning drive and swap 
the unit select plugs. (Note that switching to another drive will cause the 
volume to undergo offline mount verification. Once that completes, the 
write-lock mount verification continues.) 

When the mount verification software that polls the disk drive determines 
that the volume is in a writeable state, I/O operations to the disk are allowed 
to proceed. However, OPCOM does not issue a message indicating that 
the write-lock mount verification has completed. Instead, OPCOM issues a 
message in the following format to alert the operator that the device is write 
locked: 

%%%%%%%%%%% OPCOM, dd-mmm-yyyy hh:mm: ss . cc ’/.'/.'/.'/.'/.*/.'/.'/.'/.'/.*/. 

Device 'device-name' has been write locked. 

Mount verification in progress. 

You can toggle the WRITE LOCK switch on the drive to eliminate the write 
lock condition. I/O operations to the disk resume, with no further messages. 


7.6.3 Canceling Mount Verification 

You can cancel a mount verification request in one of three ways: 

1 Allow the mount verification in progress to continue the number of 
seconds defined by the system parameter MVTIMEOUT. When the time 
expires, the system automatically cancels the pending mount verification. 
Note that a mount verification initiated by a write lock will not time out. 

2 Invoke a special canceling routine from the console terminal. 

3 Dismount the volume with the DCL command DISMOUNT from a process 
that is not hung. 

These methods are discussed in the following sections. 


7.6.3.1 MVTIMEOUT System Parameter 

The MVTIMEOUT system parameter defines the time (in seconds) that is 
allowed for a pending mount verification to complete before it is automatically 
canceled (see the discussion of SYSGEN in the VAX/VMS System Generation 
Utility Reference Manual). This dynamic parameter should always be set to a 
reasonable value for the typical operations at your site. (See Section 11 for 
instructions on how to display and modify dynamic system parameters with 
SYSGEN). Note that resetting the value of the MVTIMEOUT parameter will 
not affect a mount verification that is currently in progress. 

You will probably find that 10 minutes (600 seconds) is a good value for 
MVTIMEOUT, whether you normally operate with or without an operator. 

When a pending mount verification is canceled by timing out, OPCOM prints 
a message in the following format: 

mmmn OPCOM, dd-mmm-yyyy hh:mm:ss.cc ’/.'/.7.’/.'/.'/.'/.'/.'/.7.7. 

Mount verification aborted for device 'device-name'. 


After a mount verification times out, all pending and future I/O requests 
to the volume will fail. Thus, the disk must be dismounted and remounted 
before it can be accessed again. 
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Note that a write-lock mount verification will not time out. 


7.6.3.2 Cancellation Commands 

If you must stop a mount verification before the time specified by 
MVTIMEOUT can elapse, enter the following sequence of commands from 
the console terminal of your VAX processor: 

[CTRLVP] 

»>HALT 
»>D/I 14 C 
»>CONT 
IPO 

While you are at the IPO prompt, all system operation is suspended. (Press 
CTRL/Z when you are ready to exit.) 

Note the following special characteristics of the mount verification canceling 
routine: 

• Lowercase characters are converted to uppercase. 

• Illegal characters (such as most control characters) are not echoed; instead, 
the terminal bell character is issued as a warning alarm. 

• Leading spaces are ignored and are not echoed. 

• Multiple spaces are compressed into a single space; that is, all space 
characters after the first are ignored. 

There are four commands you can enter in response to the IPO prompt: 


IPC> C device-name 

This command cancels any pending mount verification on the device 
specified. (A warning is given if no mount verification was in progress for 
that device.) 

IPC> x 

This command transfers control to the debugging tool XDELTA (provided 
it was loaded with the system by setting the appropriate value in the 
bootstrap file). If XDELTA has not been loaded, the prompt IPO is 
reissued. XDELTA, which is described in the VAX/VMS Delta/XDelta 
Utility Reference Manual, may prove especially useful if you are debugging 
privileged software on a VAX-11/782 attached processor system. 

IPO q 

This command recalculates the quorum on a cluster (applies to cluster 
environment only). 

IPO CTRL/Z 

Press CTRL/Z to exit from the mount verification canceling routine and 
resume system operation. 

When a pending mount verification is canceled, OPCOM prints a message in 
the following format: 

mmnm OPCOM, dd-mmm-yyyy hh:mm:ss.cc VX/X/X/X/X/. 

Mount verification aborted for device 'device-name.' 
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After you successfully cancel a pending mount verification with this 
technique, you must dismount and then remount the volume before you 
can access it again, as shown in the following example: 

mnmm OPCOM, 15-JUN-1986 10:54:54.12 
Device DBAO: is offline. 

Mount verification in progress. 


1 CTRL/P 1 

»>HALT 
>»D/I 14 C 
»>C0NT 
IPC>C DBAO 
IPC>~Z 

’/.SYSTEM-1-MOUNTVER, _DBA0: has aborted mount verification, 
mmmn OPCOM, 15-JUN-1986 10:56:26.13 
Mount verification aborted for device DBAO: 

In this example, you observe that device DBAO is off line, but are unable to 
spin the disk back up. There is no other available drive on the controller, so 
it is not possible to switch the unit select plugs of the two drives. You also 
reject the possibility of issuing a DISMOUNT command for the disk, because 
it was mounted as a private volume. 

Rather than wait ten minutes for the mount verification to time out, you 
can invoke the cancellation commands at the console terminal. Observe that 
the %SYSTEM-I-MOUNTVER message also appears here because this is the 
console terminal. 


7.6.3.3 Dismounting the Volume 

In some cases, you can abort mount verification by dismounting the volume 
in question. This only works if it is possible for you to issue the DCL 
command DISMOUNT for the volume. To do so, follow these steps: 

1 Log in at another terminal or use any logged-in terminal that has access to 
the volume. 

2 Enter the DISMOUNT/ABORT command for the volume. 

3 When you cancel a pending mount verification by dismounting the 
volume, OPCOM issues a message in the following format: 

mmmm OPCOM. dd-mmm-yyyy hh:mm: as .cc . %%%%%%%%%%% 

Mount verification aborted for device 'device-name.' 

If you do not have access to the volume, you will receive an error 
message. You can try again if you can find an appropriate process to 
use. If your process hangs, it is the system file ACP that is hung, and you 
cannot use this technique to cancel mount verification. 

4 Once the cancellation succeeds, remove the volume from the drive. 
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7.7 Backing Up Public Volumes 

This section provides system management procedures and considerations for 
backing up public files and volumes. Backing up a volume means copying 
the contents of the volume to another volume or set of volumes (for example, 
another disk or magnetic tape). It is a precautionary measure to allow you 
to recover from the loss or destruction of valuable information. Most sites 
establish a policy and a schedule for regularly backing up files on public 
volumes. 

It is just as desirable to back up private volumes as public. However, 
responsibility for backing up the files on private volumes usually is left to 
the individual owners of those files and volumes. The Guide to VAX/VMS 
Disk and Magnetic Tape Operations provides a comprehensive introduction to 
the use of the Backup Utility, including detailed information about backup 
media and tasks. 

There are two kinds of backups for public disk files and volumes: 

• Incremental (or partial). Rather than save all the files on a volume every 
time a save is performed, it is more time efficient to save only those files 
that were created or modified since the last save operation. This type of 
selective backup is termed an incremental backup. Incremental backups are 
described in Section 7.7.4. 

• Full (or all-inclusive). 

The backup medium, in either case, can be disk or magnetic tape. Incremental 
backups efficiently capture only those files that have been modified since the 
last full backup. Periodic full backups are necessary to provide the basis for 
reconstruction of a lost volume. 

As a rule, incremental backups are performed more frequently than full 
backups. You should decide, after consulting with users of the system, how 
frequently to back up files and volumes and how long to retain backup media. 
Generally, you are responsible for setting up a schedule for backing up files 
and volumes and for maintaining this schedule. 

The following schedule for backing up public disk volumes on magnetic tape 
affords adequate protection of data for many installations: 

• Daily—An incremental backup retained for 7 days. This schedule requires 
7 daily magnetic tape-sets that are rotated on a weekly basis. 

• Weekly—An incremental backup retained for 4 weeks. This schedule 
requires 4 weekly sets of magnetic tapes that are rotated every 4 weeks. 

• Monthly—An all-inclusive backup retained for a year. This schedule 
requires 12 monthly sets of magnetic tapes that are rotated annually. 

Despite all precautions, there is always the risk of losing a file. Frequent 
backups and longer retention periods reduce this risk. 

You can perform full backups either to magnetic tape or to another disk. 
Each has its advantages and disadvantages. The advantage of using magnetic 
tape for backups is the much lower media cost. The lower cost may in turn 
permit you to retain backups longer than you would if you were keeping full 
backups on disk. 
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There are several advantages to keeping backups on disk, which in some 
cases outweigh the higher cost of disk media: 

• Disks exhibit better data reliability. 

• Disks tend to degrade more slowly in storage. 

• If you have to restore data from its backup medium, a disk backup volume 
can be ready for immediate use, whereas you must first restore a magnetic 
tape to disk. 

• If you use disks for your backups, you can make use of a "rotating backup 
set," in which several disks or sets of disks are used in rotation on the 
system. At the end of each period of use (for example, once a month), 
the volume or volume set currently in use is copied to the oldest set of 
disks, the current volume is retired, and the new copy is put online for use 
during the next period. 

The remainder of this section describes backup tasks that are oriented toward 
system management; it is intended as a guide to aid system managers in 
maintaining the integrity of public files and volumes in a typical operating 
system environment. It does not, however, include standalone BACKUP. 

For specific instructions on running standalone BACKUP (including steps for 
backing up and restoring the system disk), see Section 2. 

You should refer to the VAX/VMS Backup Utility Reference Manual for 
complete information on the VAX/VMS Backup Utility and its qualifiers. 

For a detailed approach to the use of BACKUP media and tasks, refer to the 
Guide to VAX/VMS Disk and Magnetic Tape Operations. 


7.7.1 Rotating Backup Sets 

A rotating backup set on disk offers two major advantages: 

1 Your backup copy (the volume or volume set just retired) is known to 
be good, since it has been in use. The integrity of the new copy will be 
confirmed by its subsequent use; any defects discovered can be repaired 
using the backup copy. 

2 The free space on the new volume is compressed, and all the files on it 
are made contiguous or almost contiguous, resulting in better file system 
performance. 

The disadvantages to a rotating backup set are as follows: 

1 Rotating backup sets are more vulnerable to disk errors than sets created 
by retiring the copy and continuing to run with the original. A disk error 
during the copy operation results in corrupted data on your new volume; 
disk errors in directories or file headers will result in the loss of one or 
more files. Thus, you must monitor the copy operation very carefully for 
errors and manually repair any problems that arise. 

2 Files created with explicit placement lose their placement when the 
volume is copied. You should therefore not use a rotating backup set 
if the volume's primary contents are a set of database files that were 
carefully placed for optimized performance. 

3 Rotating backup sets are expensive to apply to fixed-media disks (as 
opposed to removable media). 
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7.7.2 Backing Up Full Volumes and Volume Sets 

If you want to back up an entire disk volume or volume set, you should 
use the /IMAGE qualifier of the Backup Utility. You can perform an image 
backup in a copy operation (disk to disk) or in a save operation (to disk or 
magnetic tape). When you use the /IMAGE qualifier in a save operation, 
BACKUP creates a save set that contains data necessary for reinitializing the 
disk volume. (The attribute record that contains this information is called the 
save-volume summary record.) 

When you use the /IMAGE qualifier in a copy or restore operation, the output 
volume is reinitialized; the restored volume is a functionally equivalent copy 
of the original volume. If the output volume has already been initialized as a 
Files-11 volume, you can use the /NOINITIALIZE qualifier to reinitialize the 
volume using the volume initialization parameters found on the volume. 

You cannot use other file selection qualifiers with the /IMAGE command 
qualifier. All files on the disk are saved, including reserved files and lost files 
(files that have no directory entry). 

You should specify the /RECORD qualifier if you are performing the full 
volume backup in conjunction with incremental backups that use the 
/RECORD qualifier. This is because the /RECORD qualifier causes the 
Backup Utility to write the date and time of the backup into the file header. 
Subsequently, if you specify the /SINCE=BACKUP qualifier the next BACKUP 
will only copy those files created or modified since the recorded date and 
time. 

You can back up an entire volume set by following the same procedures 
outlined in the next section for backing up a disk volume. Simply name the 
device on which the root volume (volume number 1) is mounted. 


7.7.2.1 Backing Up a Public Disk to Disk 

The procedure below describes how to copy the contents of a public disk 
to another disk. (A public disk is a disk that has been mounted with the 
/SYSTEM qualifier.) 

You should make certain that your target volume has sufficient free space. 
You need only write lock the source volume device to prevent users from 
changing any data on the disk. However, users still can read data. 

1 Issue the following command to warn all users that the disk will be 
dismounted and write-locked for backup: 

$ REPLY/ALL/BELL "message-text" 

This message should include the name of the source disk being write- 
locked and indicate in how many minutes the write lock will occur. 

2 Use the SHOW DEVICE/FILE command to ensure that all files on the 
disk have been closed; then broadcast messages to users who have open 
files, as necessary. 

3 At the time indicated by the message, issue the DISMOUNT 
/NOUNLOAD command to logically dismount the source disk as follows: 

* DISMOUNT/NOUNLOAD device-name: 

4 Write lock the source disk by pressing the WRITE PROTECT switch to 
the ON position. This switch is located on the front panel of the disk 
drive. 
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5 Mount the source disk again as follows: 

$ MOUNT/SYSTEM device-name: volume-label 

6 Place the target disk in the drive and ready the device by pressing the 
RUN/STOP button or the START/STOP switch. 

7 Mount the target volume as follows: 

$ MOUNT/FOREIGN device-name: 

8 Invoke the Backup Utility as follows: 

$ BACKUP/IMAGE/VERIFY input-device: output-device: 

If BACKUP returns any error messages, refer to the VAX/VMS System 
Messages and Recovery Procedures Reference Manual. 

9 Dismount the target volume with the following command: 

$ DISMOUNT device-name: 

10 Remove the target volume from the drive and place a label on the outside 
of the volume; the label should include the volume label and current date. 

11 Dismount the source disk by issuing the DISMOUNT/NOUNLOAD 
command as follows: 

$ DISMOUNT/NOUNLOAD device-name: 

1 2 Write enable the source disk by pressing the WRITE PROTECT switch to 
the OFF position. 

1 3 Remount the source disk with the MOUNT command as follows: 

$ MOUNT/SYSTEM device-name: volume-label 

14 Inform all users that the source disk is no longer write-locked by issuing 
the following command: 

$ REPLY/ALL/BELL "message-text" 


The following example illustrates these procedures: 

$ REPLY/ALL/BELL "DMA2: WILL BE WRITE-LOCKED IN 5 MINS. FOR BACKUP." 
Reply received on N0DE1 from SYSTEM at N0DE1.0PA0: 06:31:29 
DMA2: WILL BE WRITE-LOCKED IN 5 MINS. FOR BACKUP. 

$ SHOW DEVICE/FILES DMA2: 


$ DISMOUNT/NOUNLOAD DMA2: 

$ MOUNT/SYSTEM DMA2: PUBLIC 
7.M0UNT-I-WRITEL0CK, volume is write-locked 
‘/.MOUNT-1-MOUNTED, PUBLIC mounted on _DMA2 : 

$ MOUNT/FOREIGN DMA1: 

‘/.MOUNT-1-MOUNTED, PUBLIC mounted on _DMA1: 

$ BACKUP/IMAGE/VERIFY DMA2: DMA1: 

•/.BACKUP-1-STARTVERIFY, starting verification pass 
$ DISMOUNT DMA1: 

$ DISMOUNT/NOUNLOAD DMA2: 

$ MOUNT/SYSTEM DMA2: PUBLIC 

‘/.MOUNT-1-MOUNTED, PUBLIC mounted on _DMA2: 

$ REPLY/ALL/BELL "DMA2: IS NO LONGER WRITE-LOCKED." 

Reply received on N0DE1 from SYSTEM at NODEl.OPAO: 06:46:44 
DMA2: IS NO LONGER WRITE-LOCKED. 
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You can use BACKUP either to copy files to the new disk or to create a save 
set on the new disk. If you create a save set on the new disk, you must first 
create a directory to which the save set will be written and you must use the 
/SAVE_SET output qualifier. The directory must be included in the save-set 
name or it must be the default directory. 

For example: 

$ SHOW DEFAULT 
DMA1:[SYSTEM] 

$ BACKUP/IMAGE DMA1: DB4: [BACKUPS]21JANDMA1.BCK/SAVE.SET 


7.7.2.2 Backing Up a Public Disk to Magnetic Tape 

If you use magnetic tape as the backup medium, you may need to mount 
additional magnetic tapes. The number depends on the size of the disk being 
saved and the amount of space in use on the disk. 

An image backup operation to magnetic tape always creates a save set; 
therefore, you need not include the /SAVE—SET output qualifier. To perform 
the operation, you should follow the steps given in Section 7.7.2.1 for backing 
up to disk. However, if you are using a fresh magnetic tape, you should 
initialize it by including the /REWIND qualifier with the BACKUP command. 

For example: 

$ BACKUP/IMAGE/VERIFY/REWIND DRA1: MTAO:1JUN.BCK 


7.7.2.3 Backing Up a Disk Volume Set When Drives Are Limited 

When you use BACKUP with a volume set, you must mount all volumes 
of the set. Therefore, it may not be possible to copy a large volume set 
directly to disk if you have a limited number of disk drives. You can copy 
the volume set one volume at a time with the BACKUP/IMAGE/VOLUME 
command, using one more drive than the number of volumes in the volume 
set. You must write lock the volume set during the entire procedure to ensure 
consistency. 

For example: 

$ REPLY/ALL/BELL "DRAO:, DRA1:, AND DRA2: VOLUME SET WILL BE - 
_$ WRITE-LOCKED IN 5 MINS. FOR BACKUP." 

Reply received on N0DE1 from SYSTEM at N0DE1.0PA0: 06:31:29 

DRAO:, DRA1:, AND DRA2: VOLUME SET WILL BE WRITE-LOCKED IN 5 MINS. FOR BACKUP. 

$ DISMOUNT/NOUNLOAD DRAO: 

$ MOUNT/SYSTEM/NOWRITE DRAO:.DRA1:,DRA2: PUBLIC01,PUBLIC02,PUBLIC03 
AMOUNT-I-MOUNTED, PUBLIC01 mounted on .DRAO: 

‘/.MOUNT-I-MOUNTED, PUBLIC02 mounted on _DRA1: 

AMOUNT-I-MOUNTED. PUBLIC03 mounted on _DRA2: 

$ MOUNT/FOREIGN DRA3: 

•/.MOUNT-1-MOUNTED. SCRATCH01 mounted on _DRA3: 

$ BACKUP/IMAGE/V0LUME=1 DRAO: DRA3: 

$ DISMOUNT DRA3: 

$ MOUNT/FOREIGN DRA3: 

%M0UNT-I-MOUNTED, SCRATCH02 mounted on _DRA3: 

$ BACKUP/IMAGE/VOLUMES DRAO: DRA3: 

$ DISMOUNT DRA3: 

$ MOUNT/FOREIGN DRA3: 

AMOUNT-I-MOUNTED. SCRATCH03 mounted on _DRA3: 

$ BACKUP/IMAGE/V0LUME=3 DRAO: DRA3: 

$ DISMOUNT DRA3: 

$ DISMOUNT/NOUNLOAD DRAO: 
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$ MOUNT/SYSTEM DRAO:,DRA1:,DRA2: PUBLICOl,PUBLIC02,PUBLIC03 
‘/.MOUNT-1-MOUNTED, PUBLICOl mounted on _DRAO: 

'/MOUNT -1 -MOUNTED, PUBLIC02 mounted on _DRA1: 

•/.MOUNT-1-MOUNTED, PUBLIC03 mounted on _DRA2: 

$ REPLY/ALL/BELL "DRAO:, DRA1:, AND DRA2: VOLUME SET IS NO LONGER - 
_$ WRITE-LOCKED " 

Reply received on N0DE1 from SYSTEM at NODEl.OPAO: 06:46:44 
DRAO:, DRA1:, AND DRA2: VOLUME SET IS NO LONGER WRITE-LOCKED. 

In this example, the operator needs to back up a three-volume set. Thus, 
at least four drives are required. The operator warns the users that drives 
DRAO, DRA1, and DRA2 are about to be write-locked for backups. Next the 
operator issues MOUNT commands for the volumes PUBLICOl, PUBLIC02, 
and PUBLIC03 on drives DRAO, DRA1, and DRA2, respectively, to specify 
write locking with the /NOWRITE qualifier. Note that PUBLICOl is the 
root volume. A scratch volume is mounted on drive DRA3 to be used for 
the target volumes. As the volume on DRA3 is filled, it is dismounted and 
a new scratch volume is mounted. This procedure repeats until the third 
volume has been copied. Then the last volume on DRA3 is dismounted. To 
enable writing on the volume set again, the operator dismounts (but does not 
unload) DRAO, and then mounts the volumes again, omitting the /NOWRITE 
qualifier. As a final step, the operator announces to the users that the volume 
set is available again for writing. 

Note: Dismounting the public volume set, remounting write-locked, and so 

forth, are critical to the success of the operation. Do not simply write lock 
a mounted volume; doing so is likely to cause errors and/or suspension of 
system activity. 


7.7.2.4 Writing Save Sets on Sequential-Disk Volumes 

As an alternative to standard Files-11 structure, you can write save sets to 
disk sequentially, as they would be written on magnetic tape. The primary 
advantage in using sequential-disk save sets is that you can treat the disk 
volume as you would a magnetic tape save set; this flexibility allows you to 
mount multivolume save sets one volume at a time. 

To save data to a sequential-disk save set, make certain that the output 
specifier includes a device name for a disk device, a save-set name, and the 
qualifier /SAVE_SET; do not include a directory name. 

To write sequential-disk save sets, you must mount the output disk with the 
/FOREIGN qualifier. Although the volume is mounted foreign, BACKUP 
manages the disk using Files-11 structure. 

Volumes that are to be used for sequential-disk save sets either should be 
freshly initialized or should contain only save sets. Volumes that have been 
used for general file processing are usually unsuitable for sequential-disk use. 
You can initialize the volume by using the BACKUP qualifier /INITIALIZE. 

Note that unless you use the /INITIALIZE qualifier, the following restrictions 
apply to the output volume: 

• The disk must be Files-11 Structure Level 2. 

• The disk must not be part of a normal Files-11 volume set. 

• The cluster factor of the disk must be 1. 

• The free space on the disk cannot be fragmented into more than 100 
contiguous extents. 

• The index file cannot be extended. 
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• The master file directory (MFD) cannot be extended. 

For example, you can use the following commands to mount and initialize 
a sequential disk on drive DMAO and write the file CONTRACTS.DAT to a 
save set named CONTRACTS.BCK: 

$ MOUNT/FOREIGN DMAO: 

$ BACKUP/LOG CONTRACTS.DAT DMAO:CONTRACTS.BCK - 
_$ /SAVE_SET/INITIALIZE/LABEL=SAVEWORK 
y.BACKUP-S-COPIED, copied DBA2 : [USER] CONTRACTS . DAT; 1 

The MOUNT/FOREIGN command tells BACKUP to write to the output 
volume sequentially. The /SAVE_SET qualifier on the BACKUP command 
output specifier is necessary for writing the output file in BACKUP format. 
The /INITIALIZE qualifier destroys any previous structure information on 
the disk, enables the volume to be overwritten, and assigns the volume label 
SAVEWORK. 

When you initialize the volume, the volume label you specify is permanent; 
that is, the label remains in effect until either of the following takes place: 

• You change it with the DCL command SET VOLUME/LABEL. 

• The volume is reinitialized. 

See the VAX/VMS Backup Utility Reference Manual for more information 
on BACKUP/INITIALIZE. See the VAX/VMS DCL Dictionary for more 
information on SET VOLUME. 

Writing Multivolume Sequential-Disk Save Sets 

You may find the multi volume option particularly useful if your system has 
no tape drive but does have a large fixed-media disk and a small removable 
disk. When one sequential disk is full, BACKUP prompts you for another 
disk, as it would for save sets on magnetic tape. The following example 
demonstrates how you can use more than one disk device at a time to save or 
restore data: 

$ BACKUP DLAO:[000000]SAVE.BCK/SAVE,DLA2: DRA2: 

In this example, processing is continued on disk DLA2:, while disk DLAO: 
is spinning down. Note that you need the user privilege LOG—IO to read 
or write a multivolume sequential-disk save set. See the VAX/VMS Backup 
Utility Reference Manual for more information. 

BACKUP normally does not initialize the first sequential-disk volume, as 
the default is /NOINITIALIZE; however, continuation volumes are always 
initialized. You can initialize the first volume of a sequential-disk save set by 
specifying the /INITIALIZE qualifier. 

Note: A set of disks written with BACKUP'S sequential-disk handling is 

referred to as a loosely coupled volume set. That is, it lacks some of 
the informational structures that are present in a normal volume set, 
such as the volume set list file. Because of the subtle differences in the 
structure, you should not write files onto a sequential-disk volume as if it 
were a normal Files-11 disk; confusing and somewhat obscure errors may 
result. Because the sequential-disk volumes are part of a volume set, they 
cannot be processed individually by the Verify Utility. 
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7.7.3 Performing Selective Backups 

You may find selective backups necessary for certain groups of files that 
require special treatment. Generally, if files must be backed up regularly, 
you should create a command procedure that contains the required backup 
commands. (For more information on creating command procedures, see the 
Guide to Using DCL and Command Procedures on VAX/VMS.) 

One way to perform selective backups is through the use of wildcards. You 
can use the asterisk wildcard (*) to select files by file name, file type, or 
version number. The command in the following example selects files by 
version number and copies them to the directory [SAVE] on a specified RK07 
drive: 


$ BACKUP/LOG * . * ; 3 DMA1:[SAVE] 

•/.BACKUP-S-CREATED, created DMA1: [SAVE] CHARTS .DAT;3 
•/.BACKUP-S-CREATED, created DMA1: [SAVE] FIGURES . DAT; 3 
•/.BACKUP-S-CREATED, created DMA1: [SAVE]LISTS.DAT;3 
7.BACKUP-S-CREATED, created DMA 1: [SAVE] TABLES . DAT; 3 

The commands in the next example copy files from a directory and a directory 
tree on DMAO: to newly created directories on DMA1:. All files in the 
[GEORGE] directory and its subdirectories on the source disk are copied to 
directories with the same names on the target volume; the 
/OWNER_UIC=ORIGINAL qualifier ensures that the output files retain the 
owner UICs of the input files. All files with the file name DUNGEON in the 
[SYSEXE] directory on the source disk are copied to the [SYSEXE] directory on 
the target volume. 

$ BACKUP DMAO:[GEORGE...] DMA1:[*...]/OWNER_UIC=ORIGINAL 
$ BACKUP DMAO:[SYSEXE]DUNGEON.*;* DMA1:[SYSEXE] 

BACKUP has qualifiers that allow you to select files according to criteria such 
as UIC, creation date, expiration date, and modification date. For example, 
you can select files according to UIC by using the /OWNER_UIC qualifier as 
follows: 


$ BACKUP/LOG [.MEM]/0WNER_UIC=[300, 


•/.BACKUP■ 
•/.BACKUP- 
•/.BACKUP- 
•/.BACKUP- 
•/.BACKUP- 
•/.BACKUP- 
•/.BACKUP- 
'/.BACKUP- 
•/.BACKUP- 


S-CREATED, 
S-CREATED, 
S-CREATED, 
S-CREATED, 
S-CREATED, 
S-CREATED, 
S-CREATED, 
S-CREATED, 
S-CREATED, 


created 

created 

created 

created 

created 

created 

created 

created 

created 


$1$DLA2 

$1$DLA2 

$1$DLA2 

$1$DLA2 

$1$DLA2 

$1$DLA2 

$1$DLA2 

$1$DLA2 

$1$DLA2 


16] $1$DLA2:[USER] 

[USER]ASSIGN.LIS;1 

[USER]BBALL.DIS;19 

[USER]BBLEAGUE.FISTATEMENT;1 

[USER]BRULES.LIS;1 

[USER]GYM.MAI;1 

[USER]INF0.DAT;2 

[USER]MEMO.MAI;1 

[USER]NEWS.MAI;1 

[USER]TEAM.LIS;19 


In this example, all files residing in the subdirectory [.MEM] with an owner 
UIC of [300,16] are processed. Note that the brackets are required when you 
specify the UIC code. You can specify the UIC of the current default process 
by simply entering the /OWNER_UIC qualifier without a code. 

If you want to select your input files according to their date of creation, you 
can use the /CREATED qualifier with /BEFORE or /SINCE. The following 
command copies all files in the directory [TRUBBLE] that were created on or 
since April 3, 1986: 

$ BACKUP DMAl:[TRUBBLE]*/SINCE ss 03-APR-1986/CREATED DBA2:[SPRS] 

You can use the /EXPIRED qualifier with /SINCE or /BEFORE to select files 
according to the expiration date recorded in the file header: 

$ BACKUP *.COB;*/BEF0RE=2O-JUL-1986:/EXPIRED MFAO:JUL20SAVE.BCK 
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In this example, all versions of all files in the current default directory that 
have a file type of COB and an expiration date earlier than July 20, 1986, will 
be saved to JUL20SAVE.BCK on MFAO:. 

In some cases, you may find it more practical to exclude certain files from a 
backup operation. You can do this as in the following example: 

$ BACKUP DBA2:[OSCAR...]/EXCLUDE*(*.LOG;*,NOTES.*;*) MTA1:SAVE.BCK 

This command directs BACKUP to save all the files in the directory [OSCAR] 
and its subdirectories, except for those with a file type of LOG and those 
with the file name NOTES, regardless of file type or version number. 

The parentheses are required when a list is specified with the /EXCLUDE 
qualifier. 


7.7.4 Performing Incremental Backups 

To perform incremental backups, use the /SINCE=BACKUP input qualifier 
and the /RECORD command qualifier. The /SINCE=BACKUP input qualifier 
directs BACKUP to select only those files that have been created or modified 
since the last BACKUP/RECORD operation. The /RECORD qualifier directs 
BACKUP to record the current date in the backup date field of each file's 
header. 

For example: 

$ BACKUP/RECORD DB2:[*...]/SINCE=BACKUP MTAO:190CT.BCK 

To use the /RECORD command qualifier, you must own the files or have the 
user privilege SYSPRV. 

Note: If you use the /RECORD command qualifier to perform incremental 

backups on disk volumes, it is a good idea to discourage its use by other 
users. Incomplete backups will occur if other users perform backups 
using the /RECORD command qualifier. 

The drawback to performing incremental backups is that you accumulate a 
large number of magnetic tape or disk volumes containing the incremental 
save sets. 


7.7.5 Performing Daily Backups 

In performing daily backups, you should follow the suggestions in 
Section 7.7.4 for incremental backups, but you may want to include 
the /IGNORE=INTERLOCK qualifier. This qualifier instructs BACKUP 
to copy files even if they are open for writing; this means that you 
may produce a copy of a file in its partial state. If you do not use the 
/IGNORE=INTERLOCK qualifier, an open file will generate an error 
message and will not be backed up. The file will not be saved until the 
next incremental backup. 

You may find the /IGNORE=INTERLOCK qualifier especially useful if you 
have files that are always open (and would never be backed up otherwise). 

For example: 

$ MOUNT/FOREIGN MTAO: 

‘/.MOUNT-1-MOUNTED. INCD5J mounted on _MTA0: 

$ BACKUP/IGN0RE=INTERLOCK/RECORD/SINCE=BACKUP - 
_$ PUBLIC: [*...] MTAO:INCD12JUN 
$ DISMOUNT MTAO: 
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Note that the /IGNORE=INTERLOCK qualifier requires the user privilege 
SYSPRV, a system UIC, or ownership of the volume. 


7.7.6 Performing Weekly Backups 

You can perform weekly backups in much the same manner as daily backups. 
However, the /SINCE qualifier specifies the date of the last weekly backup, 
normally one week earlier. 

The following example assumes that the current date is 14-OCT-1986: 

$ MOUNT/FOREIGN MTAO: 

‘/.MOUNT-1-MOUNTED, INCW7J mounted on _MTAO: 

$ BACKUP/IGN0RE=INTERL0CK/REC0RD/SINCE=7-0CT-1986 - 
_$ PUBLIC:[*...]MTAO:INCW14JUN 
$ DISMOUNT MTAO: 


7.7.7 Performing Monthly Backups 

Monthly backups should be all-inclusive; that is, they should be full backups. 
Thus, you specify the /IMAGE qualifier to copy not just the files, but all the 
information required to initialize the volume or volume set when you need to 
perform a restore operation. 

For example: 

$ MOUNT/FOREIGN MTAO: 

•/.MOUNT-1-MOUNTED, FULLMA mounted on _MTAO: 

$ MOUNT/FOREIGN MTA1: 

•/.MOUNT-1-MOUNTED, FULL02 mounted on _MTA1: 

$ BACKUP/IMAGE/IGNORE=INTERLOCK/RECORD PUBLIC: - 
_$ MTAO:FULLJUN82.MTA1 

‘/.BACKUP-1-RESUME, resuming operation on volume 2 
'/.BACKUP-1-RESUME, resuming operation on volume 3 
•/.BACKUP-1-RESUME, resuming operation on volume 4 


$ DISMOUNT MTAO: 
$ DISMOUNT MTA1: 


7.7.8 BACKUP Media Security 

The file system treats a BACKUP save set, whether it is stored on disk or 
on magnetic tape, as a single file. BACKUP does not check protection on 
individual files within the save set except when restored to the original 
structure. Therefore, it is crucial to the system's file security to protect save 
sets adequately. You should assign save-set files a restrictive file protection. 
You can use the /OWNER_UIC and /PROTECTION qualifiers of the 
BACKUP command, as described in the VAX/VMS Backup Utility Reference 
Manual. Provide physical security for save sets that you keep offline (for 
example, magnetic tapes and sequential disks); if possible, you should lock 
them up. 

If a user comes to you wanting to restore a particular file, you should not lend 
the backup volume because you could give away access to all the files on the 
volume. The safest way to restore a particular file is for you to mount the 
volume and restore the file with a command such as the following: 

$ BACKUP MTAO:SAVESET/SELECT=[JONES.TEXTPROC]LASTMONTH.DAT [*...] - 
_$ /OWNER_UIC=ORIGINAL 
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The file will be restored with its original directory, ownership, and protection, 
allowing the file system to determine whether the user was ever allowed 
access to the file. 


7.7.9 Using BACKUP Journal Files 

A BACKUP journal file contains a record of BACKUP save operations and the 
file specifications of the files that were saved with each operation. To find a 
particular file in a multivolume save set, you can review the BACKUP journal 
file to find the magnetic tape volume that contains the file. 

Use the /JOURNAL qualifier to create, or append information to, a 
BACKUP journal file. If no file specification appears with the /JOURNAL 
command qualifier, the name of the BACKUP journal file defaults to 
SYS$DISK:BACKUP.BJL. The default file type for BACKUP journal files is 
BJL. 

If the specified BACKUP journal file does not exist, it is created; if it already 
exists, the new journal information is appended to the existing journal file. 
You can start a new version of a BACKUP journal file by creating an empty 
file with an editor such as EDT or the DCL command CREATE. 

To list the contents of a BACKUP journal file, enter a command in this format: 

$ BACKUP/LISTOfile-spec]/JOURNAL[=file-spec] 

You must not specify an input- or output-specifier with a BACKUP 
/JOURNAL/LIST command. If the file specification is omitted from the 
/LIST qualifier, output is directed to SYS$OUTPUT; if the file specification 
is omitted from the /JOURNAL qualifier, the default BACKUP journal file is 
used. 

You can use file selection qualifiers with the BACKUP/JOURNAL/LIST 
command. They allow you to locate a set of files in a save set just as the 
DIRECTORY command allows you to locate a set of files on a disk. The 
following example shows all files in the directory [SMITH.PROGS] backed up 
after October 5, 1986, listed in the BACKUP journal file ARCH.BJL: 

$ BACKUP/JOURNAL/LIST=ARCH.BJL/SELECT=[SMITH.PROGS]/SINCE=5-0CT-1986 

Example 7-1 shows the use of BACKUP journal files: 


7.7.10 Backing Up the Console Medium 

The procedures for backing up and restoring the console medium are 
processor dependent. You can find descriptions of the procedures for specific 
VAX processors in Section 2. 


7.7.11 Backing Up the System Disk (Using Standalone BACKUP) 

To back up and restore the system disk, you should use standalone BACKUP 
as described for your VAX processor in Section 2. 
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Example 7-1 Using BACKUP Journal Files 


$ BACKUP/JOURNAL/LOG/IMAGE DRA2: MTAO:30CT.FUL 
'/.BACKUP-S-COPIED, copied DRA2: [COLLINS] ALPHA. DAT; 4 
'/.BACKUP-S-COPIED, copied DRA2 : [COLLINS] EDTINI. EDT; 5 


'/.BACKUP-I-RESUME, resuming operation on volume 2 
'/.BACKUP-I-READYWRITE, mount volume 2 on _MTAO: for writing 
Press return when ready: I RET| 

'/.BACKUP-S-COPIED, copied DRA2: [LANE]MAIL.MAI; 1 
'/.BACKUP-S-COPIED, copied DRA2: [LANE]MEMO.RNO;5 


$ BACKUP/JOURNAL/LIST 
Listing of BACKUP journal 

Journal file _DB2: [SYSMGR]BACKUP.BJL;1 on 3-0CT-1986 00:40:56.36 
Save set 30CT.FUL created on 3-0CT-1986 00:40:56.36 
Volume number 1, volume label 30CT01 
[COLLINS]ALPHA.DAT;4 
[COLLINS]EDTINI.EDT;5 
[COLLINS]LOGIN.COM;46 
[COLLINS]LOGIN.COM;45 
[COLLINS]MAIL.MAI;1 
[COLLINS]MAR.DIR;1 
[COLLINS.MAR]GETJPI.EXE;9 
[COLLINS.MAR]GETJPI.LIS;14 


[LANE]LES.MAI;1 


Save set 30CT.FUL created on 3-0CT-1986 00:40:56.36 
Volume number 2, volume label 30CT02 

[LANE]MAIL.MAI;1 
[LANE]MEMO.RNO;5 
[LANE]MEMO.RNO;4 


[WALTERS.VI]KD.RNO;52 
End of BACKUP journal 


7.7.12 Restoring Entire Disk Volumes 

The command format for restoring from a save set is as follows: 

BACKUP save-set-specifier[/SAVE_SET] output-specifier 

You must use the /SAVE_SET qualifier when the save-set specifier refers to 
a disk volume. For tape volumes, the /SAVE_SET qualifier is the default. 

To restore an entire disk volume from a save set that was created using the 
/IMAGE command qualifier, you must mount the new volume using the DCL 
command MOUNT/FOREIGN. You must then restore the volume with the 
BACKUP/IMAGE command. 

When a save set is created using the /IMAGE command qualifier, the data 
necessary for reinitializing the volume is placed in the save set. When the 
/IMAGE command qualifier is used to restore the volume, the new volume is 
initialized using that data in the save set. 
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For example: 

$ MOUNT/FOREIGN DRA1: 

‘/.MOUNT-1-MOUNTED, 24JUND mounted on _DRA1: 

$ BACKUP/IMAGE MTAO:24JUNDMA1.BCK DRA1: 

The volume is initialized using the initialization parameters saved in the save 
set. All files and directories in the save set are restored to the new volume. 

Note: All previously stored information on the output disk is lost. 

To restore a volume set in image mode, you must mount all the volumes 
of the set as foreign volumes. You must also, in the output-specifier of the 
BACKUP command, include the list of devices on which the volumes are 
mounted. 

For example: 

$ MOUNT/FOREIGN DRAO: 

7.M0UNT-1-MOUNTED. PUBLIC01 mounted on _DRAO: 

$ MOUNT/FOREIGN DRA1: 

AMOUNT-I-MOUNTED, PUBLIC02 mounted on _DRA1: 

$ MOUNT/FOREIGN DRA2: 

AMOUNT-I-MOUNTED, PUBLIC03 mounted on _DRA2: 

$ BACKUP/IMAGE MTAO:31JUNPUB DRAO:,DRA1:,DRA2: 

The volumes receive volume set numbers in the order in which they are listed 
in the BACKUP command. In this example, DRAO, DRA1, and DRA2 become 
volumes 1, 2, and 3, respectively. 

Changing Volume Initialization Parameters Before Restoring 

If you wish to change the volume initialization parameters for a volume, you 
need to perform the following steps: 

1 Initialize the new volume using the new initialization parameters. 

2 Mount the new volume using the /FOREIGN qualifier. 

3 Restore the volume with BACKUP, using the /NOINITIALIZE command 
qualifier. 

In the following example, the cluster size of the volume is being changed 
to 3. The other volume initialization parameters take the default values from 
the INITIALIZE command. 

$ ALLOCATE DRA2: 

7.DCL-I-ALL0C, _DRA2: allocated 
$ INITIALIZE/CLUSTER_SIZE=3 DRA2: TEST.PROGS 
$ MOUNT/FOREIGN DRA2: 

7.M0UNT-1-MOUNTED. TEST.PROGS mounted on _DRA2: 

$ BACKUP/IMAGE/NOINITIALIZE/TRUNCATE MTAO:1JUN.BCK DRA2: 

The only initialization parameter that you cannot change is the structure level 
of the volume. If you change the cluster factor, as in the above example, it 
is a good practice to include the /TRUNCATE qualifier, particularly if you 
reduce the cluster factor. 
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7.7.13 Restoring a Volume from Incremental Backups 

If you have been performing a combination of full and incremental backups 
on a public volume, you must use the following procedure to recover the 
volume from its backups, should the volume be lost, corrupted, or destroyed. 

First, restore the volume from the last full backup, using an image restore 
operation as shown in the following example (the /RECORD qualifier is 
required for the correct operation of this procedure): 

$ MOUNT/FOREIGN DRAO: 

•/.MOUNT-1-MOUNTED, SCRATCH mounted on _DRAO: 

$ MOUNT/FOREIGN MTAO: 

‘/.MOUNT-1-MOUNTED, FULLMA mounted on _MTAO: 

$ MOUNT/FOREIGN MTA1: 

•/.MOUNT-1-MOUNTED, FULL02 mounted on _MTA1: 

$ BACKUP/IMAGE/RECORD MTAO:FULLJUN84.MTA1 DRAO: 

•/.BACKUP-1-RESUME, resuming operation on volume 2 
'/.BACKUP-1-RESUME, resuming operation on volume 3 
'/.BACKUP-1-RESUME, resuming operation on volume 4 


$ DISMOUNT MTAO: 

$ DISMOUNT MTA1: 

$ DISMOUNT/NOUNLOAD DRAO: 

Now mount the disk as a file-structured volume and apply the incremental 
backups in reverse chronological order. Start with the last daily backup; 
then apply the preceding daily backups, and finally the weekly backups, as 
follows: 

$ MOUNT DRAO: PUBLIC 

•/.MOUNT-1-MOUNTED, PUBLIC mounted on _DRAO: 

$ MOUNT/FOREIGN MTAO: INCD17 

•/.MOUNT-1-MOUNTED. INCD17 mounted on _MTAO: 

$ BACKUP/INCREMENTAL MTAO:INCD17JUN DRAO: 

$ DISMOUNT MTAO: 


$ MOUNT/FOREIGN MTAO: INCD16 
•/.MOUNT-I-MOUNTED, INCD16 mounted on _MTAO: 
$ BACKUP/INCREMENTAL MTAO:INCD16JUN DRAO: 
$ DISMOUNT MTAO: 


$ MOUNT/FOREIGN MTAO: INCD15 
•/.MOUNT-1-MOUNTED, INCD15 mounted on _MTAO: 
$ BACKUP/INCREMENTAL MTAO:INCD15JUN DRAO: 
$ DISMOUNT MTAO: 


$ MOUNT/FOREIGN MTAO: INCW14 
•/.MOUNT-1-MOUNTED, INCW14 mounted on _MTAO: 
$ BACKUP/INCREMENTAL MTAO:INCW14JUN DRAO: 
$ DISMOUNT MTAO: 


$ MOUNT/FOREIGN MTAO: INCW7J 

•/.MOUNT-1-MOUNTED, INCW7J mounted on _MTAO: 

$ BACKUP/INCREMENTAL MTAO:INCW7JUN DRAO: 

$ DISMOUNT MTAO: 
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In this example, applying the latest incremental backup using the 
/INCREMENTAL qualifier causes the volume's directories to be restored 
to their state at the time the backup was taken. In addition, all the files in the 
incremental save set are restored. Files that are present on the volume from 
the full restore operation, but are not listed in the most recent directory 
structure from the incremental backup, are deleted. (These files were 
deleted by users during the time period between the full backup and the 
last incremental backup.) 

In applying the earlier incremental backups, BACKUP restores the remaining 
files that have directory entries on the volume. These are files that were last 
modified some time before the last incremental backup, and were still present 
when the last incremental backup was taken. 

Note: BACKUP will restore the volume correctly regardless of the order in 

which the incremental backups are applied; using reverse chronological 
order is most efficient. 

The /RECORD and /INCREMENTAL qualifiers must be used where shown 
in the above example to obtain the correct operation. 

If you choose to selectively exclude certain files in your incremental backups 
(for example, listing files or batch logs), these files will not be restored, but 
will have directory entries in the resulting volume. You can clean up these 
"null" directory entries by running a repair pass with the VAX/VMS Verify 
Utility (VERIFY). For more information on VERIFY, see the VAX/VMS Verify 
Utility Reference Manual. 

Note that if directory files were renamed during the time period covered by 
the incremental backups, these directories will appear on the reconstructed 
volume under both their old and new names. The files that were written 
since the directory was renamed will appear under the new name; the other 
files, written before the directory was renamed, appear under the old name. 
You must merge the old and new directories manually. 


7.7.14 Restoring Files and Directories 

You can restore individual files in large save sets by using the BACKUP/LIST 
/JOURNAL command to find the volume that contains the files. You can 
then mount the volume and use BACKUP to select and restore the desired 
files. If the volume is not the first volume in a multivolume save set, you will 
receive the following warning message: 

'/«BACKUP-W-N0T1STV0L, tape 'name' is not the start of a save set 


7.7.14.1 Listing the Contents of a BACKUP Save Set 

You can use the /LIST command qualifier to list information about files in 
a save set, either at the terminal or in a specified output file. BACKUP can 
perform this operation in conjunction with any other BACKUP operation, or 
by itself. 

The following command will list save-set information at the terminal: 

$ BACKUP/LIST 2MAR1986.BCK/SAVE.SET 

To list the same information in a file named INFO.LIS, enter the following 
command: 

$ BACKUP/LIST=INFO.LIS 2MAR1986.BCK/SAVE.SET 
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If you do not know the save-set names on a magnetic tape volume, you can 
specify the device alone. Note, however, that BACKUP then performs the 
list operation as it would a restore operation with only a device specification: 
It reads the first save set it encounters on the magnetic tape and stops 
processing when it reaches the end of that save set. BACKUP does not 
automatically rewind until it reaches the end-of-tape (EOT) (unless you have 
specified the /REWIND qualifier); therefore, you can proceed to the next save 
set (if any exists) by repeating the command. 

By including an asterisk (*) with the device specification, you can direct 
BACKUP to list all of the save sets (including file names) on the volume: 

$ BACKUP/LIST MTAO:* 

If you want to list only the names of the save sets on a volume, without the 
names of the files in the save sets, you can mount the magnetic tape volume 
as Files-11; then use the DCL command DIRECTORY. For example: 

$ MOUNT MTAO: SAVEWORK TAPE 
•/.MOUNT-1-MOUNTED, SAVEWORK mounted on _MTAO: 

$ DIRECTORY/SIZE/DATE/PROTECTION TAPE: 

Directory MTAO:[] 

CONTRACTS.BCK;1 5 13-JUN-1986 12:11 

JUL20SAVE.BCK;1 3 20-JUL-1986 23:59 

MYPHILE.BCK;1 2 28-SEP-1986 12:00 

Total of 3 files, 10 blocks. 

Note: Although you can use the DIRECTORY command to list the save sets on 
a volume, the VMS file system will not necessarily be able to process save 
sets as files. 


(RWED,RWED,RE,) 
(RWED,RWED,RE,) 
(RWED,RWED,RE,) 


7.7.14.2 Restoring Disk Files from Save Sets on Magnetic Tape 

You can restore all files in the save set to the current default directory as in 
the following example: 

$ BACKUP TAPE:N0V12SAVE.BCK [] 

The following command restores files to a directory tree: 

$ BACKUP TAPE:N0V12SAVE.BCK [LYKINS. .] 

If you want to restore a specific file from a save set, you can use the /SELECT 
qualifier. For example: 

$ SET DEFAULT [LYKINS.GLENDO] 

$ MOUNT/FOREIGN MTAO: 

‘/.MOUNT-1-MOUNTED, N0V25A mounted on _MTA0: 

$ BACKUP 

.From: MTAO:N0V2SAVE.BCK/SELECT=[LYKINS.GLENDO]STRATI.DAT;5 
.To: STRATI.DAT;5 

$ DIRECTORY STRATI.DAT 
Directory [LYKINS.GLENDO] 

STRATI.DAT;5 
Total of 1 file. 

In this example, the file STRAT1.DAT in the subdirectory [LYKINS.GLENDO] 
has been accidentally deleted. The user had previously saved the file in the 
save set NOV2SAVE.BCK, and now restores it to its original directory by 
using the /SELECT qualifier. 

If you omit a save-set name for an input magnetic tape, BACKUP reads the 
first save set it encounters on the magnetic tape and stops processing when 
it reaches the end of that save set. Since BACKUP does not automatically 
rewind until it reaches the EOT, you can proceed to the next save set (if any 
exists) by repeating the command. As an alternative, you can include an 
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7.7.14.3 


asterisk (*) with the device specification, which directs BACKUP to read all 
of the save sets on the magnetic tape volume. 


Restoring Disk Files from Save Sets on Sequential Disk 

You can read a sequential-disk save set either sequentially or as a normal 
Files-11 save set. 

If you choose to read the save set as sequential, you can mount one volume 
at a time (as you can do when you create a sequential-disk save set). The 
default directory for the save-set file specification is the directory [000000], 
which is the master file directory (MFD) on the disk; therefore, you do not 
need to include the directory in the input specification. For example: 

$ MOUNT/FOREIGN DMAO: 

$ BACKUP/LOG DMAO:CONTRACTS.BCK/SAVE_SET CONTRACTS.DAT 
'/.BACKUP - S - CREATED, created DBA2 : [USER] CONTRACTS. DAT; 1 

Since the volume is mounted foreign, the DCL command DIRECTORY would 
fail to list the files on the disk. However, BACKUP recognizes the format and 
expects to find the save set CONTRACTS.BCK in the MFD directory. The 
/SAVE_SET qualifier is required on any operation that restores from disk. 

As an alternative, you can read the save set as a normal Files-11 volume: 

$ MOUNT DMAO: SAVEW0RK 

$ BACKUP/LOG DMAO:[OOOOOO]CONTRACTS.BCK/SAVE.SET CONTRACTS.DAT 
'/.BACKUP-S-CREATED, created DBA2: [USER] CONTRACTS. DAT; 1 

The default directory is your process default directory, so you must specify 
the directory [000000]. The SAVE—SET qualifier is necessary for restoring the 
file to its original structure; without the /SAVE—SET qualifier, the save set 
would simply be copied. 

Save-set files written to disk using the file system can also be read in 
sequential mode; you may find this mode of operation useful if you use 
standalone BACKUP. You must specify the directory from which the save set 
is to be read. If the save set was written to a volume set using Files-11 disk 
structure, you must observe the following rules: 

• All volumes of the volume set must be mounted. You must mount the 
volumes with the /FOREIGN qualifier. (If you are using standalone 
BACKUP, the volumes are implicitly mounted.) 

• When you specify the volumes in the input specifier, you must specify 
the names of the devices in the same order as the relative volume number 
of the volumes mounted on those devices. For example, the volumes 
named USER01 and USER02 in a volume set are mounted on two drives, 
DR A3: and DRA5:. The save-set specifier for the volume set must be in 
the following format: 

DRA3:[directory]save-set-name.ext;v, DRAB: 
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7.7.14.4 Restoring Disk Files from Save Sets on Multiple Volumes 

If your save set encompasses more than one magnetic tape or sequential disk 
volume, it is possible to begin restore operations without mounting the first 
volume of the save set. However, if you use the /IMAGE qualifier, processing 
must begin with the first volume. If the tape that you mount is not the first 
volume in the save set, you will receive the warning message: 

%BACKUP-W-N0T1STV0L, tape 'name' is not the start of a save set 

If you restore a small number of files from a large save set, it is a good idea 
to use the /LOG qualifier. This enables you to monitor the files as they are 
restored. BACKUP will continue processing until it reaches the end of the 
save set. Once the files you need have been restored, you can press CTRL/Y 
to terminate processing. 


7.8 Managing Disk Space 

Parkinson's Law, as applied to public disk storage, states that user files will 
expand to exceed the available disk storage space. To combat this problem, 
you can 

• Set file expiration dates 

• Establish disk quotas 


7.8.1 Setting File Expiration Dates 

File expiration is a file system feature (available on Files-11 Structure Level 
2 disks only) that uses the expiration date of each file to track the file's use. 
The expiration dates aid the disposal of seldom used files. 

To enable the setting of expiration dates, use the DCL command SET 
VOLUME: 

$ SET VOLUME device-name: /RETENTION=(min,max) 

For min and max you specify the minimum and maximum retention periods 
for files on the volume, expressed as delta time values. For example, the 
following command sets the minimum retention period to 15 days and the 
maximum to 20 days: 

$ SET VOLUME DRAO: /RETENTION(15-0:0.20-0:0) 

The retention periods operate as follows: every time a user accesses a file 
(for either a read or write operation), and that file's expiration date is earlier 
than the current date plus the minimum retention period, the file's expiration 
date is updated to the current date plus the maximum retention period. 

Thus, the expiration date of a frequently accessed file fluctuates between 
the minimum and maximum period plus the current date. When you set a 
suitable interval between minimum and maximum retention periods, you can 
trade between accuracy and efficiency in maintaining expiration dates. The 
difference between the two periods is the interval at which the expiration date 
of a frequently accessed file will be updated. 

If you specify only a single value in the SET VOLUME/RETENTION 
command, it becomes the minimum retention period; the maximum retention 
period is set to twice the minimum or the minimum plus 7 days, whichever is 
less. 
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You can simulate the maintenance of "access dates," available in some other 
operating systems, by setting the retention periods to very small values 
(for example, 1 hour). Note, however, that doing so will incur substantial 
overhead in the file system in updating expiration dates so frequently. 

This feature does not automatically remove unused files; it maintains 
expiration dates to permit you to develop your own policy for handling 
files with little or no activity. For example, the following BACKUP command 
will copy to tape and then delete all expired files: 

$ BACKUP/DELETE PUBLIC/BEFORE=TODAY/EXPIRED MTAO:ARCH20JUN 

Users may not always be aware of file expiration dates. Plan to retain the 
tape for a substantial period of time unless you are unperturbed by user ire. 

Note: If you start maintaining expiration dates on a previously existing volume, 
you should be aware that the expiration dates on existing files are zero 
(until the files are accessed). Files with expiration dates of zero are 
considered expired. 


7.8.2 Establishing Disk Quotas 

You limit the amount of space available to individual users on public volumes 
(or volume sets) by creating and maintaining quota files on those volumes. 
Individual users can similarly restrict usage on private volumes. Quotas are 
maintained and enforced on a per-volume basis. Each volume or volume set 
has its own quota file; a volume on which quotas are not maintained has no 
quota file; on a volume set, volume 1 contains the quota file. Each entry in a 
quota file includes the following information: 

• UIC—UIC of a user entitled to maintain files on the volume 

• Usage—Number of blocks on the volume taken up by the user's files 

• Quota—Maximum number of blocks on the volume that the user's files 
can take up before an error message is issued 

• Overdraft—Number of blocks over the quota that the user's files can 
take up 

The absolute maximum number of blocks permitted a user on a volume is the 
sum of the quota and the overdraft. 

You (or the user maintaining the volume) identify UICs and assign quotas 
and overdrafts with the Disk Quota Utility (see the VAX/VMS Disk Quota 
Utility Reference Manual). Usage counts are maintained automatically by the 
system during normal file activities. 

The name of the quota file is [OOOOOOJQUOTA.SYS on the applicable volume. 
A quota file requires one block of disk storage for each 16 entries. 

A quota file is initialized with an entry for UIC [0,0]. The usage count for 
this UIC should not change from 0—the UIC should own no files. Its quota 
and overdraft, however, serve as defaults in certain situations, and so should 
be set to values most likely to be assigned as quotas and overdrafts to other 
UICs. 
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7.8.2.1 Disk Quota Operations 

During normal use of a volume with a quota file, the system automatically 
updates the usage counts as users create, delete, extend, and truncate files. 
Users without entries in the quota file are not allowed to create files or 
allocate space on the volume, unless they have the EXQUOTA privilege. 

Exceeding the Quota 

To create new files, a user's usage must be below quota (not overdraft). If an 
operation to add a new file or expand a current file will put a user's usage 
count over the quota, the system prohibits the operation and issues an error 
message. 

If the rejected operation is an extension of a file opened for write, a user 
with an overdraft can perform the operation by retrying it. Operations to 
extend the file will succeed until usage exceeds the sum of the quota and the 
overdraft. At this point, the system prohibits further extensions to the file. 

Quota restrictions are not enforced for users with the EXQUOTA privilege. 
However, their usage counts are maintained. 

Suspending Quotas 

The DISABLE command of the Disk Quota Utility suspends quota operations 
on a volume; the ENABLE command lifts the suspension. In addition, quota 
operations on a volume can be suspended at mount time by specifying the 
/NOQUOTA qualifier to the DCL command MOUNT. Note that when you 
suspend and then resume quota operations on a volume, you will probably 
find incorrect usage values in the quota file. You can correct the usage values 
with the REBUILD command of the Disk Quota Utility or with the Verify 
Utility. (See the VAX/VMS Disk Quota Utility Reference Manual and the 
VAX/VMS Verify Utility Reference Manual for more information. 

To discontinue quota operations on a volume, execute the DISABLE 
command, exit from DISKQUOTA, and delete the QUOTA.SYS file. 

Ensuring Quota File Accuracy with REBUILD on Mount 

When a volume is mounted that was not properly dismounted the last time 
it was used, the system performs an automatic REBUILD operation. If quotas 
are enforced on the volume, this action ensures that the quota file accurately 
reflects usage of the disk, should any of the following occur: 

• The system failed. 

• The volume was physically removed before being dismounted. 

• The WRITE PROTECT button was pushed. 

7.8.2.2 Restrictions on Other System Operations 

The following restrictions and limitations apply whether or not disk quotas 
are being used: 

• The SYSPRV privilege is required to change the owner UIC of a file, 
because a change in file ownership consumes the resources of another 
user. 

• Relative volume 1 of the volume set must be on line at all times. 
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You can enhance the performance of selected executable and shareable images 
by installing them as known images with the Install Utility (INSTALL). 
INSTALL is described in the VAX/VMS Install Utility Reference Manual. 

The system defines known images on internal data structures called known file 
lists. Each known file list contains entries for all known images whose 
device, directory, and file type are identical. For example, all known 
images with the filename DISK$VOLUME:[MAIN]filename.EXE would 
be on one known file list, while all known images with the filename 
DISK$VOLUME:[TEST]filename.EXE would be on another known file list. 

Known file lists only last while the system is up. If the system is shut 
down or fails for any reason, you must reinstall all known images after the 
system is rebooted. For this reason, the site-independent startup command 
procedure, SYS$SYSTEM:STARTUP.COM, includes a series of INSTALL 
commands that install certain system programs as known images. You 
are encouraged to include in the site-specific startup command procedure, 
SYS$MANAGER:SYSTARTUP.COM, additional INSTALL commands to 
install any images that 

• Are run frequently 

• Are usually run concurrently by several processes 

• Require special privileges 

(See Section 2 for information on the startup command procedures.) 


8.1 Assigning Attributes to Known Images 

By specifying appropriate INSTALL qualifiers, you can assign known images 

the following attributes: 

• Permanently open—Directory information on the image file remains 
permanently resident, eliminating the usual directory search required 
to locate a file. The cost of keeping an image file permanently open is 
approximately one page of nonpaged dynamic memory per file. 

• Fleader resident—The header of the image file (native images only) 
remains permanently resident, saving one disk I/O operation per file 
access. For images with single-block file headers, the cost is less than 
one page of paged dynamic memory per file; for images with multiblock 
headers, the cost varies according to the header block count. The images 
must also be declared permanently open. 

• Privileged—Amplified privileges are temporarily assigned to any process 
running the image (executable images only), permitting the process to 
exceed its UAF privilege restrictions during execution of the image. In 
this way, users with normal privileges can run programs that require 
higher-than-normal privileges. 
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• Protected—A shareable image contains protected code, that is, code that 
runs in kernel or executive mode but that can be called by a user-level 
image. Protected images must be declared shared. 

• Shared—More than one user can access the read-only and non-copy- 
on-reference read/write sections of the image concurrently, so that only 
one copy of those sections ever need be in physical memory. (Copy-on- 
reference sections always require a separate copy for each process.) The 
image must also be declared permanently open. 

• Writeable—When a shared non-copy-on-reference writeable section 
is removed from physical memory (for paging reasons or because no 
processes are referencing it), it is written back to the image file. Any 
updates made by processes mapped to the section, therefore, are preserved 
(while the initial values are lost). The image must also be declared shared. 


8.2 Installing Images with the Shared Attribute 

Before you install an image with the shared attribute (using the /SHARED 
qualifier of the Install Utility), you should understand the distinction between 
executable and shareable images: 

• An executable image is one linked with the /EXECUTABLE qualifier 
(or without the /SHAREABLE qualifier) of the VAX/VMS Linker. (For 
information on the VAX/VMS Linker, refer to the VAX/VMS Linker 
Reference Manual.) 

• A shareable image is one linked with the /SHAREABLE qualifier of the 
VAX/VMS Linker; it must subsequently be linked into an executable 
image to be used. (Shareable images are sometimes referred to as linkable 
images, because they can be specified—implicitly or explicitly—as input 
files to the link of another file.) A shareable image is not copied into the 
executable images that link with it. Thus, only one copy of the shareable 
image need be on disk, no matter how many executable images have 
linked with it. 

When an image is not installed, or is installed without the shared attribute, 
each process running the image requires private sections in memory. (A 
shareable image linked to an executable image need not be installed to be 
executed. At image execution time, the system will create private sections 
from the shareable image. The only exception is that a shareable image 
containing a writeable non-copy-on-reference section must be installed as a 
known image with the shared and writeable attributes.) 

When you install an image with the shared attribute, permanent system 
global sections are created. Execution of non-copy-on-reference global 
sections requires only one copy per section to be in physical memory, no 
matter how many processes are running the image to which the sections 
belong. 

The number of images that you can install with the /SHARED qualifier is 
restricted by the GBLPAGES and GBLSECTIONS system parameters (see 
the description of the System Generation Utility in the VAX/VMS System 
Generation Utility Reference Manual). 
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8.3 Installing Images with Privileges 

VAX/VMS allows images to execute in an enhanced privilege environment 

through two mechanisms: 

• You can install existing executable images with extra privileges to allow a 
nonprivileged process to perform the privileged functions of the image. 

• You can install privileged shareable images. Privileged shareable images 
are used to implement user-written system services, thereby allowing 
nonprivileged images to execute select portions of privileged code, without 
enhancing the privileges of each image that uses the privileged portion of 
code. 


8.3.1 Privileged Executable Images 

You install executable images with enhanced privileges through use of the 
/PRIVILEGED qualifier of the Install Utility. Only images that are linked 
with the VAX/VMS Linker qualifiers /NODEBUG and /NOTRACE should 
be installed with enhanced privilege. Installing other images with enhanced 
privilege can compromise system security. 


8.3.2 Privileged Shareable Images 

VAX/VMS supports user-written system services through a mechanism called 
privileged shareable images. (See the VAX/VMS System Services Reference 
Manual for a description of how to create privileged shareable images.) 

You must link a privileged shareable image with the /PROTECT command 
qualifier or the /OPTIONS positional qualifier of the VAX/VMS Linker, so 
that the image acquires its particular form of enhanced privileges: 

• Use the /PROTECT command qualifier when all parts of an image require 
protection. 

• Use the /OPTIONS positional qualifier when only part of a privileged 
shareable image requires protection. 

You then install the privileged shareable image with the Install Utility, 
specifying both the /PROTECTED and /SHAREABLE qualifiers. If you fail 
to follow all these steps, you will prevent successful activation of a privileged 
shareable image. 


8.4 Installing Execute-Only Images 

The image activator allows execution of images to which the caller has 
EXECUTE but not READ access. The support differs slightly for main 
programs and shareable images. 

The Install Utility /EXECUTE _ONLY qualifier has meaning only for main 
programs. However, a main program installed with this qualifier is capable 
of activating shareable images to which the process has EXECUTE but not 
READ access. The image activator ignores this qualifier when it is used on 
images other than main programs. 
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8.4.1 Execute-Only Main Programs 

When a process runs a main program to which it has EXECUTE but not READ 
access, the image activator enters a restricted mode of operation similar to 
that entered when a privileged program is run. That is, all shareable images 
activated during the life of the execute-only program must be installed. In 
addition, the image activator directs RMS to use only "trusted" logical names 
when opening image files. Logical names associated with EXEC or KERNEL 
mode are trusted. User-mode and supervisor-mode names are not. 


8.4.2 Execute-Only Shareable Images 

Execute-only shareable images can be executed only in the restricted 
environment established when a main program that references them is 
run. The main program must be marked as capable of mapping execute- 
only shareable images (it must be installed with the INSTALL qualifier 
/EXECUTE—ONLY), and all shareable images the program references must 
be installed. 

When an installed execute-only shareable image is run, the image activator 
enters the same restricted mode of operation that it enters when it detects an 
execute-only main program. That is, only "trusted" logical names are used by 
RMS. 


8.5 Deleting Known Images and Dismounting Volumes 

System operations are affected by two characteristics of known images: 

• Deletion—A known image is not deleted as soon as the /DELETE qualifier 
is applied. The deletion occurs only after all processes using the image 
have released it. 

• Dismounting—A volume cannot be dismounted while any known file lists 
associated with it contain entries. 

To dismount a volume, then, you must not only delete all known images 
associated with it, but you must wait for all processes using those images to 
release them and for the system to write writeable images back to their files. 
You can use the DCL command SHOW DEVICES/FILES to determine the 
status of the files. 


8.6 Defining Logical Names for Shareable Image Files 

At execution time, either a shareable image must reside in the directory 
SYS$SHARE (which is normally equivalent to SYS$LIBRARY), or you must 
define a logical name for the file. The logical name must be that used as 
the input file specification for the shareable image when it was linked. The 
equivalence string is the current file specification. That is, if a shareable 
image called STATSHR.EXE does not reside in SYS$SHARE, you must, before 
running an executable image that calls STATSHR, define the logical name 
STATSHR. For example: 

$ DEFINE STATSHR SYS$SYSDEVICE:[TEST]STATSHR 

The default file type is EXE. If the file specification for STATSHR were 
SYS$SHARE:STATSHR.EXE, no DEFINE command would be necessary. 
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Likewise, one shareable image can be substituted for another without 
requiring the calling executable image to relink. The user simply 
defines the filename of the old shareable image as the logical name of 
the file specification of the new one. The following statement defines 
the filename STATSHR as the logical name of the shareable image 
SYS$SYSDEVICE:[MAIN]STATSHR.EXE for executable images calling 
STATSHR: 

$ DEFINE STATSHR SYS$SYSDEVICE:[MAIN]STATSHR 

Again the default file type is EXE. (Logical name redirection in the process 
or group logical name table is ignored when you run a privileged executable 
image. Only logical names that can be redirected by privileged users are 
allowed.) 

If the new image is installed with the /SHARED qualifier, executable images 
linked against the old image will be mapped to global sections for the new 
image. Otherwise, they will be mapped to private sections for the new image. 

As demonstrated in the previous examples, the old and new images can 
have the same name, but must reside in different directories. You should not 
substitute one version of a file for another in the same directory. 

A Note on Installing Shared Images in MA780 Multiport Memory 

To install a shared image so that the global sections will reside in a multiport 
memory unit, you issue the DCL command DEFINE (an ASSIGN command 
could also be used) to create a logical name of the form: 

GBL$filename shrmem-name:filename 

The following example ensures that any global sections created for an image 
whose file name is STATSHR reside in the MA780 multiport memory unit 
whose logical name is SHRMEM1: 

$ DEFINE GBL$STATSHR SHRMEM1:STATSHR 
$ INSTALL = "$INSTALL/COMMAND_MODE" 

$ INSTALL 

INSTALL> ADD/OPEN/SHARED STATSHR 
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Using the Batch/Print Facility 


The batch and print jobs that run on a system each day often constitute a 
large part of the workload. As system manager, you must become familiar 
with the number and types of jobs that run on your system and develop 
ways to submit, schedule, and execute them efficiently. You can manage job 
workloads and improve system performance by 

• Establishing and controlling queues 

• Establishing and controlling spooled devices 

• Controlling batch and print jobs 

This chapter provides the concepts and procedures required to carry out these 
management tasks. 


9.1 Types of Queues 

The VAX/VMS batch/print facility supports several types of queues for 
processing batch and print jobs. Queues can be divided into three major 
categories: execution, generic, and logical. Execution queues schedule jobs 
for execution; generic and logical queues transfer jobs to execution queues. 
Queue type is further defined by the kinds of jobs the queue can accept for 
processing. Some execution and generic queues accept batch jobs; others 
accept print jobs. Logical queues are restricted to print jobs. The various 
types of execution, generic, and logical queues are defined in the sections that 
follow. 


9.1.1 Execution Queues 

An execution queue schedules jobs for processing. In a VAXcluster 
environment, jobs are directed to execution queues on specific nodes within 
the cluster. The two types of execution queue, batch queue and output queue, 
are described as follows: 

• Batch execution queue - A batch execution queue can schedule only 
batch jobs for execution. A batch job executes as a detached process that 
sequentially runs one or more command procedures. You define the list of 
command procedures when you submit the job. Section 9.6 describes how 
to establish a batch execution queue. 

• Output execution queue - An output execution queue schedules print 
jobs for processing by an independent process called a symbiont. The job 
controller sends the symbiont a list of files to process. You define this list 
of files when you submit the job. An output symbiont transfers data from 
disks to an output device. As the symbiont processes each file, it produces 
output for the device it controls, such as a printer or a terminal. 

The standard print symbiont image provided by VAX/VMS is designed to 
print files on hardcopy devices. User-modified or user-written symbionts 
can also be designed for this or any other file processing activity managed 
by the VAX/VMS batch/print facility (see the VAX/VMS Utility Routines 
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Reference Manual for more information). The three types of output 
execution queues are described below: 

- Printer execution queue - Typically uses a symbiont to direct output 
to a line printer. 

- Terminal execution queue - Typically uses a print symbiont to direct 
output to a terminal printer. 

- Server execution queue - Uses a user-modified or user-written 
symbiont to process the files that belong to jobs in the queue. You 
cannot mark an output execution queue as a server execution queue 
when you create it. Only the user-written symbiont can specify that 
the associated queue be marked as a server execution queue. 

When you create an output execution queue you can initially mark it as 
either a printer or terminal execution queue. However, when the queue 
is started, the symbiont process associated with the queue can change the 
queue type from the type designated at its creation to a printer, terminal, 
or server execution queue, as described below: 

- When an output execution queue that is associated with the standard 
VAX/VMS print symbiont is started, the symbiont determines 
whether it is controlling a printer or a terminal. It communicates 
this information to the job controller. If necessary, the job controller 
then changes the type designation of the output execution queue. 

- When an output execution queue that is associated with a user- 
modified or user-written symbiont is started, the symbiont has the 
option of identifying the queue to the job controller as a server queue. 
If the user-written or user-modified symbiont does not notify the job 
controller that it wants to change the queue type, the output execution 
queue retains the queue type it received when it was created. That is, 
it remains marked as either a printer or terminal execution queue, even 
though it is associated with a nonstandard symbiont. 

Section 9.7 describes how to establish output execution queues. 


9.1.2 Generic Queues 


A generic queue holds a job until an appropriate execution queue becomes 
available to initiate the job. The job controller then requeues the job to the 
available execution queue. In a VAXcluster environment, a generic queue 
can direct jobs to execution queues that are located on other nodes in the 
VAXcluster. The two types of generic queues, generic batch queue and 
generic output queue, are described as follows: 

• Generic batch queue - A generic batch queue can direct jobs only to batch 
execution queues. Generic batch queues are used on VAXcluster systems, 
and are described in detail in the Guide to VAXclusters. Section 9.6.4 
briefly describes generic batch queues. 

• Generic output queue - A generic output queue can direct jobs to any 
of the three types of output execution queues: print, terminal, or server. 

It is possible to create a generic output queue that directs jobs to any 
combination of the three types of output execution queues. Typically, 
however, when you create a generic output queue, you specify a list of 
type-specific target queues. In this way, the generic output queue directs 
jobs to a single type of output execution queue. Thus, you can control 
whether the jobs submitted to a generic output queue are output on a line 
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printer or a terminal printer, or are sent to a user-written symbiont for 
processing. Generic output queues are described in Section 9.7.10. 


9.1.3 Logical Queues 

A logical queue performs the same function as a generic output queue, except 
that a logical queue can direct jobs only to a single printer, terminal, or server 
execution queue. A logical queue is an output queue that has been assigned 
to transfer its jobs to one execution queue. Jobs sent to a logical queue cannot 
execute until you first assign the logical queue to an output execution queue, 
and then start both the output execution queue and the logical queue. Logical 
queues are described in Section 9.7.9. 


9.2 Managing the Job Controller 

The system job controller is automatically started when the system is booted; 
the command procedure resides in SYS$SYSTEM:STARTUP.COM. If the job 
controller encounters a fatal error while trying to perform an operation on 
the system job queue file, it displays an error message on the system console, 
aborts, and then automatically restarts itself. 

If for some reason you must manually restart the JOB-CONTROL process, 
follow this procedure: 

1 Issue the SHOW SYSTEM command, to determine the identification 
numbers of all symbiont processes. 

2 Identify all symbiont processes that have a UIC of [1,4] and a name of the 
following format: 

process.id name SYMBI0NT_nnnn 

Note that user-written symbiont processes may have a process name other 
than SYMBIONT. 

3 Stop symbiont processes by using the following command format: 

STOP/ID^symbiont.process.id 

4 Invoke the STARTUP.COM procedure as follows: 

$ <DSYS$SYSTEM: STARTUP JOBCTL 


9.3 Controlling the Queue Manager 

The system queue manager controls the scheduling of batch and print jobs. 
The following sections describe how to start the queue manager and how to 
handle abnormal conditions. 
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9.3.1 Starting the Queue Manager 

You start the queue manager and open the queue file with the DCL command 
START/QUEUE/MANAGER. A new queue file is created if one does not 
already exist, or if the /NEW_VERSION qualifier is specified. The START 
/QUEUE/MANAGER command is restricted to users with both OPER 
and SYSNAM privileges. You must include this command before any 
other queue commands in your site-specific startup command procedure, 
SYS$MANAGER:SYSTARTUP.COM (see Section 2 for more information on 
SYSTARTUP.COM). 

You can specify the name of a queue file as a command parameter. If you 
omit this parameter, the job controller uses the default file specification 
SYS$SYSTEM:JBCSYSQUE.DAT. In a VAXcluster, you must include the file 
specification parameter to cause each system to access the same job queue 
manager file on a shared disk volume. The disk must be mounted before 
you issue the command. The following example includes a file specification 
parameter: 

$ START/QUEUE/MANAGER DUA2:[SYSQUE]JBCSYSQUE.DAT 

In this example, the queue file JBCSYSQUE.DAT is opened in the directory 
DUA2:[SYSQUE]. 

You can control the initial allocation and extension size of the queue file with 
the /EXTEND—QUANTITY qualifier. Specify a positive integer in the range 
of 10 through 65535, or 0. If 0 is specified, the default value is 100 disk 
blocks. 

The /BUFFER__COUNT qualifier allows you to specify the number of buffers 
in a local buffer cache to allocate for performing I/O operations to the system 
job file. The default value is 50. (See the VAX/VMS DCL Dictionary for more 
information on the START/QUEUE/MANAGER command.) 


9.3.2 Creating a New Queue File 

In the unlikely event that the queue file (SYS$SYSTEM:JBCSYSQUE.DAT) 
becomes corrupted, it will be necessary to create a new queue file. The 
following conditions may indicate a corrupted queue file: 

• Irregularities in the display produced by the DCL command SHOW 
QUEUE 

• Jobs do not process 

• Jobs seem to disappear 

Before you can create a new queue file, you must stop all execution queues 
on the system by issuing the DCL command STOP/QUEUE/MANAGER. 
This command performs an orderly shutdown of the system job queue 
manager, stops all execution queues, terminates all executing jobs, and 
denies any further queue requests. Once all queue processes are terminated, 
the queue file is closed. The STOP/QUEUE/MANAGER command 
is contained in the site-independent shutdown command procedure, 
SYS$SYSTEM:SHUTDOWN.COM. (See Section 2 for more information 
on shutdown procedures.) 

To create a new version of the queue file, issue the DCL command START 
/QUEUE/MANAGER/NEW—VERSION. 
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The STOP/QUEUE/MANAGER and START/QUEUE/MANAGER 
commands are restricted to users with both OPER and SYSNAM privileges. 


9.3.3 Restarting the Queue Manager 

By default, the queue manager does not automatically restart in the event 
of a job controller failure. However, if you specify the /RESTART qualifier 
with the START/QUEUE/MANAGER command, the queue manager is 
automatically restarted on recovery from a job controller abort. 

All batch and output queues are restored to the states that existed prior to the 
interruption of service. The job queue manager file that is opened is the same 
file that was open before the abort. Upon restarting, the job controller uses 
the default values for the /EXTEND—QUANTITY and /BUFFER-COUNT 
qualifiers. Previously set values are lost. 

Note: In order to prevent a looping condition, the job controller will not restart 
the queue manager if it detects an error within two minutes of starting 
the queue manager. 


9.4 Managing Queues 

As a system manager, you are responsible for creating and controlling queues. 
This section introduces the basic DCL commands used to manage queues and 
discusses several queue management operations. 

The basic commands for creating and controlling queues include: 


Command 

Description 

INITIALIZE/QUEUE 

Creates a queue 

START/QUEUE 

Starts a queue 

SET QUEUE 

Modifies a queue 

STOP/QUEUE 

Stops a queue 


Using specific qualifiers with these DCL commands allows you to perform the 
following queue management operations discussed in this section: 

• Initializing and starting queues 

• Modifying queues 

• Pausing queues 

• Stopping queues 

• Restarting queue processing 

• Deleting queues 

• Merging output queues 

• Restricting access to queues 
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9.4.1 Initializing and Starting Queues 

To set up a queue, you first create or initialize the queue, and then start it. 
You use the following commands to initialize and start a queue: 


Command 

Description 

INITIALIZE/QUEUE 

Initializes a queue. If the queue is already 
running, this command has no effect. 

INITIALIZE/QUEUE/START 

Initializes and starts a queue. Include 
this command for each queue in your 
SYSTARTUP.COM file. 

START/QUEUE 

Starts an initialized queue. If a queue is in a 
paused state, you can use this command to 
resume job execution. If a queue is stopped, 
you can use this command to modify job 
processing parameters. Jobs listed in the 
queue and new jobs will execute under the new 
parameters. 


The INITIALIZE/QUEUE and INITIALIZE/QUEUE/START commands are 
restricted to users with OPER privilege. The START/QUEUE command 
requires OPER privilege or EXECUTE (E) access to the queue. 

With the INITIALIZE/QUEUE/START command, you initialize and start a 
queue using a single command. This method is recommended in command 
procedures (for example, the site-specific startup command procedure 
SYS$MANAGER:SYSTARTUP.COM) where it is necessary to initialize and 
immediately start a queue if it is stopped. The following example shows the 
commands entered in a startup command procedure to initialize and start the 
batch queue SYS$BATCH and the printer queues LPAO and LPBO: 

$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=2/BASE_PRI0RITY ss 3 SYS$BATCH 
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO: 

If the commands are executed when the queue is stopped, the INITIALIZE 
/QUEUE/START command initializes and starts the queue. Otherwise, if the 
queue is already running, the command is ignored and no operation occurs. 
(See Section 2 for a description of startup command procedures.) 

Setting up queues is not restricted to startup time. In the course of normal 
operation, you can create queues as needs dictate. Typically, you use 
the INITIALIZE/QUEUE/START command to create and start a queue. 
However, separate INITIALIZE/QUEUE and START/QUEUE commands 
are useful when you want to initialize a queue but start it at a later time. 

For example, suppose you want to initialize a printer queue and make sure 
that it is set up correctly to process print jobs before you start the queue. 

By specifying appropriate qualifiers to the INITIALIZE/QUEUE command, 
you can assign specific processing attributes to the queue. Once a queue 
is created, you can also specify additional processing attributes when the 
queue is started. See Section 9.5.4 for the qualifiers to the START/QUEUE 
command. 
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9.4.2 Modifying Queues 

Once you initialize a queue, you can change many of its attributes with the 
DCL command SET QUEUE. This command is restricted to users with OPER 
privilege or E access to the queue. 

The SET QUEUE command allows you to change many queue attributes 
without having to stop the queue, initialize it, and restart it. For example, the 
following command modifies the running batch queue, SYS$BATCH: 

$ SET QUEUE/J0B_LIMIT=4/DISABLE_SWAPPING SYS$BATCH 

The command in this example changes the job limit for the queue and 
disables swapping for all jobs processed in SYS$BATCH. All other attributes 
of the queue remain the same. The changed attributes do not affect the 
execution of current jobs; however, all subsequent jobs are executed with the 
new attributes in effect. See Tables 9-2 and 9-3 for a list of the attributes 
that can be modified for batch and output queues. 


9.4.3 Pausing Queues 

The DCL command STOP/QUEUE (without any qualifiers) temporarily 
halts the execution of all current jobs in the queue and places the queue 
in a paused state. This command is restricted to users with OPER privilege 
or E access to the queue. Pausing an output queue allows you to issue 
print job positioning and alignment commands to the print symbiont. (See 
Section 9.5.4 for more information on using the STOP/QUEUE command to 
control print jobs.) 

The DCL command START/QUEUE is used to resume the execution of a 
paused queue, as described in Section 9.4.5. 


9.4.4 Stopping Queues 

To stop a queue, issue one of the following STOP/QUEUE commands, 
according to the desired stop queue operation: 


Command 

Description 

STOP/QUEUE/NEXT 

Stops a queue after all executing jobs have completed 
processing 

STOP/QUEUE/RESET 

Abruptly stops a queue and aborts processing of all 
executing jobs 


The DCL command STOP/QUEUE/NEXT allows all currently executing jobs 
to complete and then stops the queue. Once you issue this command, all new 
jobs are prevented from executing. This command is restricted to users with 
OPER privilege or E access to the queue. 

The DCL command STOP/QUEUE/RESET abruptly stops the queue and 
returns control to the system. Any jobs that are currently executing are 
stopped immediately. This command is restricted to users with OPER 
privilege or E access to the queue. 
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9.4.5 Restarting Queues 

To resume the processing of jobs in a paused or stopped queue, issue the 
START/QUEUE command in the following format: 

START/QUEUE queue-name[:] 

This command is restricted to users with OPER privilege or E access to the 
queue. 

Note: If the STOP/QUEUE/RESET command was issued to halt the queue, you 
may have to resubmit the job that was executing at the time that the 
queue was stopped. 

Jobs that are restartable by default, such as print jobs, are requeued for 
processing. Jobs that are not restartable by default must be resubmitted. To 
make batch jobs restartable, use the SUBMIT/RESTART command discussed 
in Section 9.5.5. Also, see Section 9.5.1 for information on how to retain a 
processed job in a queue. 


9.4.6 Deleting Queues 

You can delete a queue by issuing the DCL command DELETE/QUEUE. 
You must first stop the queue by issuing the DCL command STOP/QUEUE 
/NEXT. (Use STOP/QUEUE/RESET if you want to abort all executing jobs.) 
This command is restricted to users with OPER privilege. 

To delete a queue, proceed as follows: 

1 Stop the queue by issuing the STOP/QUEUE/NEXT command. 

2 Wait for executing jobs to complete. 

3 Delete or requeue the entries still pending in the queue. 

4 Delete the queue by issuing the DELETE/QUEUE command. 

The commands in the following example stop the printer queue ALTFORM, 
check the contents of the queue, and delete the empty queue: 

$ STOP/QUEUE/NEXT ALTFORM 
$ SHOW QUEUE/ALL ALTFORM 
$ DELETE/QUEUE ALTFORM 


9.4.7 Merging Output Queues 

When a problem occurs with a print device, you can reroute the queue 
associated with that device to another queue associated with a functioning 
device. Use the following procedure to merge two printers that are not 
associated with a generic queue. Note that all commands shown are restricted 
to users with the OPER privilege or E access to the queues. 

1 Stop the queue associated with the malfunctioning print device by using 
the following command format: 

STOP/QUEUE/NEXT bad.queue 

This command inhibits further queuing but allows the current job to 
finish processing, unless the print device is inoperable. If the device is 
inoperable, use the STOP/QUEUE/RESET command to halt the queue 
and immediately cancel all output to the device. 
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2 Requeue the current job by using the following command format: 

STOP/QUEUE/REQUEUE=good_queue bad_queue 

Note: If the current print job was originally submitted to a generic queue, 
the print job is automatically requeued to another device. 

By requeuing the current job, you ensure that it will be printed from 
its last checkpoint. Other jobs in the queue will not be scheduled for 
processing because the queue is stopped. 

3 Take the device offline. 

4 Reroute existing jobs queued to the malfunctioning print device to another 
print device by entering the command 

ASSIGN/MERGE good.queue bad_queue 

Check to be sure that the attributes of the new print device are appropriate 
for processing the new jobs. 

5 To prevent any subsequent print jobs from entering the bad queue, you 
can assign the name of the bad queue to the good queue, thus causing any 
new print jobs directed to the bad queue to enter the good queue. 

ASSIGN/SYSTEM bad_queue good_queue 


The following example summarizes the procedure for merging two printer 
queues that are not associated with a generic queue: 

$ STOP/QUEUE/NEXT BAD.QUE 
$ STOP/REQUEUE=GOOD_QUE BAD.QUE 
$ ASSIGN/MERGE G00D_QUE BAD_QUE 
$ ASSIGN/SYSTEM BAD.QUE GOOD.QUE 


9.4.8 Restricting Access to Queues 

Operations that apply to a queue or to specific jobs in a queue are controlled 
by UlC-based protection in the same way access to other system objects, such 
as files, is controlled. (See the discussion of protection in the VAX/VMS DCL 
Concepts Manual). The ability to control queue operations through UlC-based 
protection allows you to restrict the types of jobs and users for a particular 
queue. 

When you initialize a queue, the queue is assigned an owner UIC and a 
protection mask. Jobs are assigned an owner UIC equal to the UIC of the 
process that submitted the job. Each operation that is performed in a queue 
or job in a queue is checked against the owner UIC, protection of the queue 
and the job, and the privileges of the requester. 

All operations are checked as follows: 

• Operations that apply to jobs are checked against the READ (R) and 
DELETE (D) protection specified for the queue and the owner UIC of the 
job. In general, R access to a job allows a user to see the attributes of a 
job, and D access allows the user to delete the job. 

• Operations that apply to queues are checked against the WRITE (W) 
and EXECUTE (E) protection specified for the queue and the owner UIC 
of the queue. A user with W access to a queue can submit jobs to that 
queue. Users with E access to a queue may act as the operator for that 
queue, with the ability to affect any jobs in the queue. Users with operator 
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(OPER) privilege have E access to all queues. OPER privilege also enables 
users to establish queues and affect accounting. 

The default protection for a queue is (System^Owner.D^roup^WorkhW). 
To find out the protection specified for a particular queue use the DCL 
command SHOW QUEUE/FULL, as shown in the following example: 

$ SHOW QUEUE/FULL SYS$PRINT 
Generic printer queue SYS$PRINT 

/GENERIC=(ALPHA_LPAO, ALPHA.LPBO, COSMO.LPAO) /OWNER=[1,4] 

/PROTECTION*(S:E,0:D,G:R,W:W) /RETAIN=ERROR 

The system displays the protection code and other characteristics associated 
with the queue. Table 9-1 summarizes the privileges required for various 
queue operations. 


Table 9-1 Privilege Restrictions for Queue Operations 


Required Privilege 

Commands 

OPER and SYSNAM 

START/QUEUE/MANAGER 

STOP/QUEUE/MANAGER 

OPER 

DEFINE/CHARACTERISTIC 

DEFINE/FORM 

DELETE/CHARACTERISTIC 

DELETE/FORM 

DELETE/QUEUE 

INITIALIZE/QUEUE 

OPER, E access to 

SHOW QUEUE 

the queue, or R 
access to the job 

SYNCHRONIZE 

OPER, E access to 

PRINT 

the queue, or W 
access to the queue 

SUBMIT 

OPER or E access 

ASSIGN/MERGE 

to the queue 

ASSIGN/QUEUE 

DEASSIGN/QUEUE 

SET QUEUE 

START/QUEUE 

STOP/QUEUE 

STOP/QUEUE/NEXT 

STOP/QUEUE/RESET 

OPER, E access to 

DELETE/ENTRY 

the queue, or D 

SET QUEUE/ENTRY 

access to the job 

STOP/QUEUE/ABORT 

No privilege 

SET RESTART_VALUE 


9.5 Managing Jobs 

This section describes operations for controlling batch and print jobs. Some 
of the operations commonly performed by a system manager include: 

• Retaining jobs in a queue 

• Terminating an executing job 

• Modifying job parameters 
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• Controlling print job position and alignment 

• Controlling batch job execution 

For certain operations, the DCL command used for a batch job may differ 
from that used for a print job. The following table shows a few cases in 
which a similar operation requires a different command. 


Batch Command 

Print Command 

Function 

SUBMIT 

PRINT 

Sends a job to a 
queue 

STOP/ABORT/ENTRY= 

STOP/ABORT 

Terminates an 

entry-number 


executing job 

STOP/QUEUE/ENTRY= 

STOP/QUEUE/REQUEUE 

Stops and 

entry-number/REQUEUE 


requeues an 
executing job 


These and other DCL commands for controlling batch and print jobs 
are discussed in the following sections. (For detailed descriptions of the 
commands, see the VAX/VMS DCL Dictionary.) 


9.5.1 Retaining Jobs in a Queue 

To retain a job in a queue after it has been processed, specify the /RETAIN 
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE 
command. The /RETAIN qualifier has the following format: 

/[NO]RETAIN[^option] 

You indicate the type of job that the queue is to retain by specifying one of 
the following options: 


Option 

Description 

ALL 

Specifies that jobs be retained in the queue in a 
completed status after they are executed 

ERROR 

Specifies that jobs be retained only if they 
completed unsuccessfully (the completion status 
has the low bit clear) 


By default, jobs are NOT retained. 

The following command specifies that the queue retain all jobs that complete 
with a "nonsuccess" (low bit clear) status: 

$ SET QUEUE/RETAIN=ERROR BATCH.QUE 
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9.5.2 Deleting a Job 

Under certain circumstances, it is necessary to terminate an executing batch 
or print job. For example, you may need to terminate a program that has 
entered an endless loop or a job that is executing on a faulty print device. 

Follow this procedure to delete either a pending or an executing job: 

1 Determine the entry number of the job and the name of the queue by 
issuing the command 

$ SHOW QUEUE/BATCH/ALL 

2 Delete the job by issuing the command 

DELETE/ENTRY=entry-number queue-name 


The DELETE/ENTRY command is restricted to users with either OPER 
privilege, E access to the queue, or D access to the specified job. 

You can also use the STOP/ENTRY command to delete an executing job. 
Issue the command in the format 

STOP/ENTRY=entry-number queue-name 

The following example shows how to terminate an executing batch job: 

$ SHOW QUEUE/BATCH/ALL 
Batch queue SYS$BATCH 


Jobname 

Username 

Entry 

Status 



MAILER 

DECNET 

1701 

Holding until 

8-JUL-1986 

10:33 

ASSEM.JOBCTL 

JONES 

1152 

Holding until 

12-JUL-1986 

00:00 

Batch queue SPECIAL 





Batch queue TEXT. 

_PROC 





Jobname 

Username 

Entry 

Status 



2307SMRCL 

MARCO 

1719 

Executing 



2307SMRDS 

MARCO 

1720 

Pending 




$ ST0P/ENTRY=1719 TEXT_PROC 

Assume a user has observed that job 1719 is a runaway job. The user is not 
the owner of the job, and lacks sufficient privilege to stop it. The user enlists 
your aid as the system manager. You issue the SHOW QUEUE/BATCH/ALL 
command to determine the queue in which the job has been entered. The 
display shows that job 1719 is in the TEXT—PROC queue. You then delete 
the job by issuing the STOP/ENTRY command. 

A third option for terminating an executing job is to issue the STOP/ABORT 
command in the following format: 

STOP/ABORT queue-name 

Note: If you use the STOP/ABORT command to terminate an executing batch 
job, you must include the /ENTRY qualifier to identify the specific job 
entry. 

The STOP/ABORT command is restricted to users with either OPER 
privilege, E access to the queue, or D access to the current job. In the 
following example, the executing print job in queue LPAO is terminated, and 
the next job is immediately scheduled for printing. 

$ STOP/ABORT LPAO 
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9.5.3 Modifying Job Parameters 

You can modify certain job processing attributes by specifying the following 
qualifiers with the SET QUEUE/ENTRY command: 


Qualifier 

Description 

/[NOJAFTER 

Controls whether a job is held until after a specified time. 

/[NOJHOLD 

Controls whether a job is available for immediate processing 
or held until it is released for processing. 

/[NOJPASSALL 

Specifies whether the symbiont bypasses all formatting and 
sends the output QIO to the driver with format suppressed. 
See Section 9.7.8 for information on the /[NOjPASSALL 
qualifier. 

/PRIORITY 

Specifies the queue scheduling priority of the job. 

/RELEASE 

Releases a previously held job. 

/REQUEUE 

Requests that the job be moved from the original queue to 
the specified queue. This qualifier can also be used with the 
STOP/QUEUE/ENTRY command. 

/SETUP 

Calls for the specified modules from the device control 
library. See Section 9.7.2 for information on device control 
libraries. 


(See the VAX/VMS DCL Dictionary for complete descriptions of these 
qualifiers.) 


9.5.3.1 Holding and Releasing a Job 

The /HOLD qualifier of the command SET QUEUE/ENTRY controls whether 
a job is to be made available for immediate processing. You release a held 
job by using either the /NOHOLD or the /RELEASE qualifier. 

To request that the job be held until after a specified time, use the /AFTER 
qualifier with the command SET QUEUE/ENTRY. The job is queued for 
immediate processing when the specified time arrives. The /AFTER=time 
qualifier accepts either absolute or delta time values in the format 
[dd-mmm-yyyy] [hh:mm:ss.cc]. You can also specify the keywords: 

TODAY 

YESTERDAY 

TOMORROW 

The following command holds a print job until it is queued for processing at 
the specified date and time: 

$ SET QUEUE/ENTRY=1121/AFTER=12-JUL-1986:17:30 SYS$PRINT 

You can use the /NOAFTER qualifier to immediately release a job that is 
being held until after a specified time. 

The /RELEASE qualifier releases a job that is being held for any of the 
following reasons: 

• A job was submitted with the /HOLD qualifier 

• A completed job was held in a queue by the /RETAIN qualifier 

• A user-written symbiont has refused a job 
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• A job was submitted with the /AFTER qualifier 
This example shows how to hold and release a batch job: 

$ STOP/QUEUE/ENTRY-1234/HOLD SYS$BATCH 
$ SET QUEUE/ENTRY=1234/RELEASE SYS$BATCH 


9.5.3.2 Requeuing a Job 

To stop and requeue the executing print job, enter the STOP/QUEUE 
/REQUEUE command to suspend the currently executing job and requeue it 
to the specified queue, for example: 

$ STOP/QUEUE/REQUEUE=ALPHA_LPAO ALPHA.LPBO 

This command causes the executing print job on ALPHA_LPB0 to be stopped 
and requeued to ALPHA_LPAO. The queue does not stop; only the currently 
executing job is affected. Other jobs remain pending in the queue until they 
are processed. 

You can further qualify the STOP/QUEUE/REQUEUE command with the 
/HOLD qualifier. To hold an aborted print job, enter the STOP/QUEUE 
/REQUEUE/HOLD command in the following format: 

STOP/QUEUE/REQUEUE/HOLD [queue-name] 

When you specify /HOLD, the aborted job is placed in a hold state for later 
release with the SET QUEUE/ENTRY/RELEASE command. If you do not 
need to process a job that is being held in a queue, you can delete the job 
with the DELETE/ENTRY command. 

Note: If you are requeuing a job on a batch queue, you must include the 
/ENTRY=n qualifier, for example: 

$ STOP/QUEUE/ENTRY=1251/REQUEUE=FRED.BATCH SYS$BATCH 


9.5.3.3 Changing the Priority of a Job 

You can change the priority of a job by using the /PRIORITY=n qualifier 
with the SET QUEUE/ENTRY command. The priority value must be in a 
range of 0 through 255, where 0 is the lowest priority and 255 is the highest. 
The default value for /PRIORITY is the value of the SYSGEN parameter 
DEFQUEPRI. You must have either OPER or ALTPRI privilege to raise the 
priority value above the value of the SYSGEN parameter MAXQUEPRI. 

No privilege is needed to set the priority of your own job lower than the 
MAXQUEPRI value. The following example changes the priority of a 
job to 3: 

$ SET QUEUE/ENTRY=1131/PRI0RITY=3 SYS$BATCH 


9.5.4 Controlling Print Job Position and Alignment 

Pausing an output queue allows you to communicate with the print symbiont 
interactively. You pause a queue by issuing the STOP/QUEUE command 
(without any qualifiers). You can perform the following operations while a 
queue is paused: 

• Specify the position at which a suspended job is to resume printing 

• Specify the number of pages and the type of data for aligning printer 
forms 

These operations are described in the sections that follow. 
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9.5.4.1 Specifying the Position of Print 

You specify the position at which the current job is to resume printing by 
pausing the queue, then entering the START/QUEUE command with any of 
the following qualifiers: 


Qualifier 

Description 

/[NO]BACKWARD[=pages] 

Specifies the number of pages the file is to be 
backspaced before printing is resumed. A value 
of 1 indicates that printing is to resume at the top 
of the current page. If you omit the page value, 
the file is backspaced one page. 

/[NO]FORWARD[=pages] 

Specifies the number of pages the file is to be 
forward-spaced before printing is resumed. A 
value of 1 indicates that printing is to resume at 
the top of the next page. If you omit the page 
value, the file is forward-spaced one page. 

/[NO]SEARCH=string 

Specifies that printing is to resume at the page 
containing a particular search string. The search 
for the string moves forward, beginning on the 
page following the current page. During the 
search, consecutive tabs and spaces are treated 
as a single space, and character case is ignored. 

/TOP_OF_FILE 

Specifies that printing is to resume at the 
beginning of the file. 


When you must use more than one positioning qualifier with the same 
START/QUEUE command, file positioning is performed in the following 
order: 

/TOP 

/FORWARD 

/BACKWARD 

/SEARCH 

The command in the following example resumes output on LPAO after 
advancing 15 pages from the beginning of the file. 

$ START/QUEUE/T0P/F0RWARD=i5 LPAO: 


9.5.4.2 Aligning Printer Forms 

To print alignment data to aid in aligning printer forms, enter the 
START/QUEUE command along with the /ALIGN qualifier: 

/ALIGN=(optionl[,option2]) 

The following options control the number of alignment pages and type of 
alignment data: 
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Option Description 

MASK Specifies that input data is masked by replacing alphabetic 

characters with the character X and numeric characters with the 
number 9. Mask characters allow you to prevent the printing 
of sensitive information. If you omit the MASK option, data is 
printed unaltered. 

n A decimal number in the range 1 through 20 that specifies the 

number of alignment pages to print. By default, one page of 
alignment data is printed. 


You can use the /ALIGN qualifier along with any of the file positioning 
qualifiers described in the previous section. File positioning is performed 
before alignment data is printed. After the alignment is complete, the queue 
enters a paused state until you restart it by reissuing the START/QUEUE 
command. Printing resumes from the point that alignment data started; that 
is, the task is backspaced over the pages printed for alignment. 

The command in the following example requests masked alignment for four 
pages of output. 

$ START/QUEUE/BACKWARD*2/ALIGN=(MASK,4) LPAO: 

In this example, the file for the job that was being printed when the queue 
was paused is backspaced two pages before alignment is performed. Four 
pages of alignment mask characters are printed. Then the output for the 
current job is positioned backward four pages, and the queue pauses. 


9.5.5 Controlling Batch Job Execution 

You submit batch jobs to the VAX/VMS system and queue them for execution 
in two ways: 

• As command procedure files submitted by issuing the DCL command 
SUBMIT. These files are placed in a batch queue and selected for execution 
according to their relative priority in the queue. By default, the name of 
this batch queue is SYS$BATCH. 

• As batch job files submitted by issuing the DCL command JOB from a 
card reader. These batch job files are spooled onto a disk and placed in a 
batch queue. Unless the JOB command specifies otherwise, the name of 
this batch queue is SYS$BATCH. 

When a job executes on a batch queue, the job is assigned the attributes of 
the queue. Users, however, can explicitly override some queue attributes 
for a particular job by specifying qualifiers to the DCL command SUBMIT. 
The following qualifiers are useful for balancing the system resources for 
processing batch jobs: 
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Qualifier 

Description 

/AFTER=time 

Specifies that the job will be held until after a designated 
time. If the designated time has passed or the /NOAFTER 
qualifier is specified, the job is queued for immediate 
processing. 

/CLI 

Enables you to specify a different command language 
interpreter (CLI) to use in processing the job. 

/CPUTIME 

Defines a CPU time limit for the batch job. When a job 
needs less CPU time than authorized, use the /CPUTIME 
qualifier to override the base value established for the 
queue or authorized in your UAF. 

/PRIORITY 

Specifies the job scheduling priority for a job. You must 
have either OPER or ALTPRI privilege to raise the priority 
above the value of the SYSGEN parameter MAXQUEPRI. 
No privilege is needed to set the priority lower than the 
MAXQUEPRI value. The default priority of a queue is 
determined by the SYSGEN parameter, DEFQUEPRI. 

/WSDEFAULT 

Defines a working set default for a batch job. Use this 
qualifier to override the base value established for the 
queue. 

/WSEXTENT 

Defines a working set extent for a batch job. You cannot 
request a higher value than your default. 


See the VAX/VMS DCL Dictionary for complete descriptions of the SUBMIT 
command qualifiers. 

You can also control certain attributes of batch jobs that are submitted as 
command procedure files by issuing the following SET commands: 


Command Description 

SET OUTPUT_RATE=time Controls the rate at which output is 

written to a batch job log file. By 
default the contents of the buffer is 
written to a log file once per minute. 

SET RESTART—VALUE=string Defines the value of the symbol 

BATCHSRESTART. This symbol can 
be used to control the point at which 
a command procedure will restart after 
encountering a system interruption. 
BATCH$RESTART is the value of the 
most recently executed SET RESTART— 
VALUE command. The SRESTART 
symbol is a Boolean value which is true 
if a system interruption has occurred. 

SET QUEUE/ENTRY/NOCHECKPOINT Erases the value established by 

the most recently executed SET 
RESTART_VALUE command by 
clearing BATCHSRESTART. 


See the VAX/VMS DCL Dictionary for detailed descriptions of these SET 
commands. 
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9.6 Establishing Batch Queues 

A batch execution queue controls the execution of batch jobs, and defines 
default system resources for jobs that execute on it. Typically, you must 
decide on the number of batch queues for your installation and determine 
attributes such as the following: 

• Job limit 

• Base priority 

• Swap mode 

• CPU limits 

• Working set quotas and limits 

(See Section 6 for a discussion of limits, quotas, and priorities.) 

You control the attributes of a batch queue by issuing specific qualifiers to the 
INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command. Table 9-2 
gives a summary of the attributes that can be associated with a batch queue. 
See the VAX/VMS DCL Dictionary for complete details on the qualifiers 
described in Table 9-2. 


Table 9-2 Specifying Attributes for Batch Execution Queues 


Qualifier 

/[NOJBATCH 


/BASE_PRIORITY 

/[NOJCHARACTERISTICS 


/CPUDEFAULT 


/CPUMAXIMUM 

/[NOJDIS ABLE—SWAPPING 


/[NO]EN ABLE—GENERIC 


Description 

Indicates that you are initializing a batch 
queue. The default is /NOBATCH. For an 
existing queue, you can use the /BATCH 
qualifier only if the queue is already a batch 
queue. 

Specifies the base process priority at which 
jobs in the queue are processed. 

Specifies one or more characteristics for 
processing jobs in a queue. The default is 
/NOCHARACTERISTICS. A characteristic can 
be either a value from 0 through 127 or a 
characteristic name that has been defined by 
the DEFINE/CHARACTERISTIC command. 

Defines the base queue value for the default 
CPU time limit for batch jobs executed in this 
queue. The time cannot exceed the CPU time 
limit set by the /CPUMAXIMUM qualifier. 

Defines the maximum CPU time for batch 
jobs. Use this qualifier to override the CPU 
time limit specified in the UAF file. 

Controls whether batch jobs executed from 
a queue can be swapped in and out of 
memory. The default is /NODISABLE — 
SWAPPING. 

Specifies whether jobs queued to a generic 
queue can be placed in this queue for 
processing. The default is /ENABLE- 
GENERIC. 
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Table 9-2 (Cont.) 

Specifying Attributes for Batch Execution 
Queues 

Qualifier 

Description 

/JOB_LIMIT 

Indicates the number of batch jobs that can 
be executed concurrently from a batch queue. 

/ON=node:: 

Specifies the node on which this batch 
execution queue is located. The node name 
is used only in VAXcluster environments; 
it must match the node name specified by 
the SYSGEN parameter SCSNODE for the 
processor on which the queue executes. 

See Section 9.7.1 for information on naming 
queues. 

/OWNER_UIC 

Enables you to change the user identification 
code (UIC) for the queue. 

/PROTECTION 

Specifies the protection of the queue. By 
default, the queue protection is (SYSTEM:E, 
OWNER:D, GROUP:R, WORLD:W) 

/[NOjRETAIN 

Specifies that jobs be retained in the queue in 
a completed status after they have executed. 
The default is /NORETAIN. 

/WSDEFAULT 

Defines the base queue value for the working 
set default for batch jobs executed in this 
queue. The value set by this qualifier 
overrides the value defined in the UAF of 
any user submitting a job to the queue. 

/WSEXTENT 

Defines the base queue value for the working 
set extent for batch jobs executed in this 
queue. The value set by this qualifier 
overrides the value defined in the UAF of 
any user submitting a job to the queue. 

/WSQUOTA 

Defines the base queue value for the working 
set page size for batch jobs executed in 
this queue. The value set by this qualifier 
overrides the value defined in the UAF of any 
user submitting a job to the queue. 


Before users can submit batch jobs, the system manager must create at least 
one batch queue. Jobs will not begin processing until the system manager 
starts the batch queue. (Section 9.4.1 discusses how to create and start a 
queue.) More than one batch job can execute at the same time from a single 
batch queue. The number of jobs that can execute simultaneously depends 
on the job limit that you establish for the queue. 

After a batch queue has been started, the job with the highest relative priority 
is the first candidate for execution. For jobs having the same priority, the 
earliest submitted job is the first candidate for execution. 

You should normally encourage users to submit large jobs (such as compiling 
and linking large programs) as batch jobs, and to reserve interactive use of 
the system for jobs that do not require extensive resources. Toward this end, 
you may do the following: 

• Restrict the working set size of interactive jobs by providing a small (for 
example, 300) WSEXTENT value in the UAF records (see Section 6). 
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• Expand the working set size of batch jobs by providing a large (for 
example, 500) WSEXTENT value when you create the batch queue. 

You can likewise restrict and expand time limits on jobs by setting the CPU 
values. The following sections provide some guidelines for setting up batch 
execution queues in different environments. 


9.6.1 Setting Up Batch Queues on Small Systems 

On small systems (under 1MB), you should add up the pages required for 
the batch working sets and ensure that enough fluid memory remains for 
interactive jobs. Fluid memory can be reassigned from one process to another 
through swapping and paging. (You can calculate fluid memory as the space 
that remains when you subtract the number of pages permanently allocated 
to VAX/VMS from the total memory. To obtain these values, issue the DCL 
command SHOW MEMORY.) 

If fluid memory drops below the value of the WSMAX system parameter, 
you must reduce the number of batch jobs or make the FAST and SLOW 
jobs swappable. Otherwise, a deadlock could result. (See Section 9.6.3 for 
information on setting up FAST and SLOW queues.) 


9.6.2 Setting Up Batch Queues on Interactive Systems 

This section provides guidelines for setting up a batch queue for a system 
that is predominantly interactive. The following values are typical for a 
VAX11-780 system: 

1 Set up one batch queue named SYS$BATCH, the name of the default 
batch queue. 

2 Give SYS$BATCH the following characteristics: 

• Job limit—1 to 4 

• Base priority—3 or 4 

• Swapping mode—swapping enabled (default) 

• Working set default—300 

• Working set quota—200 to 500 

• Working set extent—400 or more 

• CPU default—infinite (default) 

• CPU maximum—infinite (default) 

Normally, you would include the following command in your site-specific 
startup command procedure to create and start this queue (see Section 2): 

$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=2/BASE_PRI0RITY=3 - 
/WSDEFAULT=3OO/WSQU0TA=5OO/WSEXTENT=2OOO SYS$BATCH 
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9.6.3 Setting Up Batch Queues on Batch Systems 

The following guidelines are useful for setting up batch queues for a system 
that is predominantly a batch system and in which editing is the principal 
interactive activity: 

1 Set up three batch queues as follows: 

• SYS$BATCH—the default batch queue with swapping enabled. 

• FAST—a queue for executing high-priority jobs that should not be 
swapped out of memory. 

• SLOW—a "background" queue for processing low-priority jobs. 
Typically, these are large jobs with large requirements for physical 
memory. Usually, it is uneconomical to swap such jobs out of memory. 
You can adjust the system workload by stopping and restarting 
background queues as needed. 

2 Give SYS$BATCH the following characteristics: 

• Job limit—6 to 10 

• Base priority—4 (by default) 

• Swapping mode—swapping enabled (by default) 

3 Give FAST the following characteristics: 

• Job limit—1 (by default) 

• Base priority—4 (by default) 

• Swapping mode—swapping disabled 

4 Give SLOW the following characteristics: 

• Job limit—1 (by default) 

• Base priority—low (3, for example) 

• Swapping mode—swapping disabled 

Normally, you would include the following commands in your site-specific 
startup command procedure to create and start these queues (see Section 2): 

$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=6 SYS$BATCH 
$ INITIALIZE/QUEUE/START/BATCH/DISABLE.SWAPPING FAST 
$ INITIALIZE/QUEUE/START/BATCH/BASE_PRI0RITY=3- 
/DISABLE_SWAPPING SLOW 


9.6.4 Setting Up Generic Batch Queues 

Unlike an output queue, a batch queue can execute more than one job at a 
time. For this reason, it is often not necessary on a single-node system to 
create more than one batch queue of the same type and assign them to a 
generic batch queue. In a VAXcluster environment, where you have multiple 
processors, generic batch queues are useful for distributing batch jobs to batch 
execution queues that are located on other nodes in the cluster. The use of 
generic batch queues in clustered environments is described in detail in the 
Guide to VAXclusters. 
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9.7 Establishing Output Queues 

An output execution queue controls the processing of print jobs by an 
independent symbiont process that is associated with the queue. As described 
in Section 9.1, there are three types of output execution queues: 

• Printer execution queue —A queue that typically uses the standard print 
symbiont to direct output to a line printer. 

• Terminal execution queue —A queue that typically uses the standard 
print symbiont to direct output to a terminal printer. (Terminal queues are 
created and controlled by the same commands as printer queues.) 

• Server execution queue —A queue that uses a user-modified or user- 
written symbiont to process the files that belong to jobs in the queue. 
(Server queues are created and controlled by the same commands as 
printer queues.) 

You control the attributes of an output queue by issuing specific qualifiers 
to the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command. 
Table 9-3 gives a summary of the attributes that can be associated with 
output queues. See the VAX/VMS DCL Dictionary for complete details on the 
qualifiers described in Table 9-3. 

Table 9-3 Specifying Attributes for Output Execution Queues 

Qualifier Description 

/BASE-PRIORITY Specifies the base process priority at which 

the symbiont serving this queue will execute. 
You must stop and restart all output queues 
sharing the symbiont to change the symbiont 
base process priority. 

/[NO]BLOCK_LIMIT Limits the size of print jobs that can be 

executed on an output queue. The default is 
/NOBLOCK_LIMIT. You can use this qualifier 
to reserve certain printers for certain size 
jobs. 

/[NOjCHARACTERISTICS Specifies one or more characteristics for 

processing jobs in a queue. The default is 
/NOCHARACTERISTICS. A characteristic can 
be either a value from 0 through 127 or a 
characteristic name that has been defined by 
the DEFINE/CHARACTERISTIC command. 

/[NOjDEFAULT Establishes defaults for certain options 

of the PRINT command. The default is 
/NODEFAULT. /DEFAULT options include 
FLAG, BURST, TRAILER, FEED, and 
FORM=type. Once an option is set for the 
queue by the /DEFAULT qualifier, users do 
not have to specify that option in their PRINT 
commands. However, users may override 
these options by including them on the DCL 
PRINT command line. 
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Table 9-3 (Cont.) Specifying Attributes for Output Execution 
Queues 

Qualifier Description 


/[NO]EN ABLE—GENERIC 


/FORM-MOUNTED 


/[NO]LIBRARY 


/ON=device[:] 

/OWNER_UIC 

/[NO]PROCESSOR 


/PROTECTION 

/[NO]RECORD_BLOCKING 

/[NO]RETAIN 

/SCHEDULE=[NO]SIZE 


Specifies whether files queued to a generic 
queue can be placed in this queue for 
processing. The default is /ENABLE— 
GENERIC. 

Specifies the form type mounted on the 
output queue. You specify the form type 
by using a numeric value or a form name 
that has been defined by the DEFINE 
/FORM command. If the stock of the form 
associated with the job is not identical to the 
stock of the form mounted on the queue, the 
job will enter a pending state. 

Specifies the file name for the device control 
library. When you are initializing an output 
queue, you can use this qualifier to specify an 
alternate device control library. The default 
library is SYS$LIBRARY:SYSDEVCTL.TLB. 

Specifies the node and/or device on which 
this execution queue is located. 

Enables you to change the user identification 
code (UIC) for the queue. 

Allows users to specify their own print 
symbiont image. The file name specifier 
can be any valid file name. It specifies 
that the symbiont image to be executed is 
SYS$SYSTEM:file-name.EXE. By default, 
SYS$SYSTEM:PRTSMB.EXE is executed. 

The /NOPROCESSOR qualifier cancels the 
effect of a previous /PROCESSOR setting. 

Specifies the protection of the queue. By 
default, the queue protection is (SYSTEM:E, 
OWNER:D, GROUP:R, WORLD:W) 

Determines whether the symbiont can block 
together output records for transmission to 
the output device. The default is /RECORD- 
BLOCKING. 

Specifies that jobs be retained in the queue in 
a completed status after they have executed. 
The default is /NORETAIN. 

Specifies whether pending jobs in a printer, 
terminal, or server queue are scheduled for 
printing based on the size of the job. When 
the default /SCHEDULE=SIZE is in effect, 
smaller jobs will print before larger ones. 


9-23 









Using the Batch/Print Facility 


Table 9-3 (Cont.) 

Specifying Attributes for Output Execution 
Queues 

Qualifier 

Description 

/[NOjSEPARATE 

Specifies the job separation attributes for 
a printer or terminal queue. Users cannot 
override these options. The default is 
/NOSEPARATE. Job separation options 
include BURST, FLAG, TRAILER, and 
RESET=module. The selected options 
establish mandatory attributes for all jobs 
processed in the queue. 

/WSDEFAULT 

Defines a working set default for the 
symbiont process. You must stop and 
restart all output queues to change the 
symbiont base process priority. 

/WSEXTENT 

Defines a working set extent for the symbiont 
process. You must stop and restart all 
output queues to change the symbiont base 
process priority. 

/WSQUOTA 

Defines the working set page size for the 
symbiont process. You must stop and 
restart all output queues to change the 
symbiont base process priority. 


Before users can submit print jobs, the system manager must initialize at least 
one output queue. Jobs will not begin processing until the system manager 
starts the queue. (Section 9.4.1 describes how to initialize and start a queue.) 

Print jobs are queued for processing in one of two ways: 

• Implicitly —without the direct intervention of a user 

• Explicitly —with the direct intervention of a user 

Implicit Printing 

Print jobs are queued implicitly when a process directs its output to a spooled 
device. The output is then placed in a temporary file. When the file is closed, 
it is submitted to an output queue. Both the spooling of the output file to 
an intermediate device and the subsequent queuing of a job consisting of 
this file occur without the direct intervention of a user. Implicit printing uses 
default attributes, and bypasses the user's ability to specify job attributes on 
the command line. Section 9.7.11 discusses spooled devices in detail. 

Explicit printing 

Print jobs are queued explicitly when users issue the PRINT command. 

Users can explicitly queue one or more files (from a disk) for printing. (The 
VAX/VMS DCL Dictionary describes the PRINT command and available 
qualifiers in detail.) The files specified in the PRINT command are queued as 
a print job; if several files make up a print job, they are printed together. 

Unlike batch execution queues, an output execution queue can print only 
one job at a time. Print jobs are scheduled for printing according to their 
priority; the highest-priority job is the first selected for printing. If several 
jobs have the same priority, the smallest job is printed first, unless the queue 
is initialized with the /SCHEDULE=NOSIZE qualifier. Jobs of equal size 
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having the same priority are selected according to their submission time; the 
job submitted earliest is printed first. 

By default, print jobs queued by issuing the PRINT command are placed 
in the queue named SYS$PRINT. Thus, to use the default version of the 
PRINT command on a system with only one printer, name the printer queue 
SYS$PRINT in your site-specific startup command procedure as follows: 

$ INITIALIZE/QUEUE/START/ON=LPAO: SYS$PRINT 

Note: To use the default version of the PRINT command on a system with 
several line printers of matching characteristics, you would normally 
establish SYS$PRINT as the name of a generic queue. Section 9.7.10 
describes how to establish generic output queues. 


9.7.1 Naming an Output Execution Queue 

By default, when you initialize an output execution queue for a particular 
printer, the queue is assigned the name of the physical device. For example, 
the following command initializes and starts the queue for the line printer 
LPAO and assigns the queue the name LPAO. 

$ INITIALIZE/QUEUE/START LPAO: 

To create an output execution queue and assign it a name that is different 
from the printer's physical device name, specify the /ON qualifier of the 
INITIALIZE/QUEUE command: 

/0N=device[:] 

The /ON qualifier allows you to assign a queue name that describes the 
printer's function. For example, you could assign the name LETTER to the 
queue for a letter quality printer. Users wanting letter-quality printing could 
simply queue their jobs to the queue LETTER. 

The following command sequence initializes and starts a queue named 
LETTER, assigns it to the printer LPCO, and then sends a print job 
(MY_LETTER.TXT) to the queue. 

$ INITIALIZE/QUEUE/START/ON=LPCO: LETTER 
$ PRINT/QUEUE=LETTER MY_LETTER.TXT 


9.7.2 Using Device Control Libraries 

A device control library is a text library that contains user-written modules for 
setting up printers to perform special printer functions. Device control library 
modules can be used for the following purposes: 

• To insert device-dependent escape sequences that set up programmable 
printers for selected print options such as point size, character set, and 
bold or italic print 

• To insert text at specific points in the processing of a print job such as at 
the beginning of a file, the beginning of each page, or at the end of each 
job (modules designed for this purpose can be used on both programmable 
and non-programmable printers) 
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You use the following DCL commands to set up device control library 
modules for processing print jobs: 


Command 

Description 

DEFINE/FORM/SETUP 

Specifies one or more modules 
that set up the device when 
the form is mounted before 
each file. 

DEFINE/FORM/[NO]PAGE_SETUP 

Specifies one or more modules 
that set up the device before 
each page. 

INITIALIZE/QUEUE/LIBRARY 

START/QUEUE/LIBRARY 

Specifies the file name 
of the device control li¬ 
brary. The default library is 
SYS$LIBRARY:SYSDEVCTL.TLB 
This parameter must contain 
a file name only, without an 
extension or a directory. 

INITIALIZE/QUEUE/SEPARATE=[NO]RESET 

ST ART/QUEUE/SEPARATE=[NO]RESET 

SET QUEUE/SEPARATE=[NO]RESET 

Specifies one or more modules 
to be extracted from the device 
control library and copied to 
the device at the end of each 
job. This module can be used 
to restore the device to a 
known state at the end of each 
job. The default is NORESET. 

PRINT/SETUP 

Calls for the specified modules 
to be extracted from the device 
control library and copied to 
the printer before a file is 
printed. 


To use a device control library module, perform the following steps: 

1 Create a device control library by issuing the command: 

$ LIBRARY/CREATE/TEXT SYS$LIBRARY:SYSDEVCTL.TLB 

2 Determine the contents of the module—either the text to be inserted, or 
the escape sequences needed for the desired printer setup. You determine 
the proper escape sequences for a printer option by referring to the 
operation guide for the specific printer. 

3 Create a module file and enter the appropriate escape sequences, carriage 
control characters, and/or text. You create and edit a module file as you 
would any other text file. 

4 Insert the module into the device control library by issuing the command: 

LIBRARY/INSERT/TEXT library-file module-file 

5 Assign the device control library to a queue by issuing the command: 

INITIALIZE/QUEUE/LIBRARY=filename queue-name 

Note that this step is not necessary if you use the default library 
SYSDEVCTL.TLB. 
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6 Request a device control library module by issuing either the 
PRINT/FORM or PRINT/SETUP command, for example: 

$ PRINT/SETUP=M0DULE1 TEST1.TXT/QUEUE=ELF_QUE 

(See the VAX/VMS Librarian Reference Manual for more information on 
creating libraries and inserting modules.) 


9.7.2.1 Assigning a Library to an Output Queue 

You assign a device control library to an output queue by specifying the 
/LIBRARY qualifier with the INITIALIZE/QUEUE or START/QUEUE 
command in the following format: 

INITIALIZE/QUEUE/START/LIBRARY=filename queue-name 

The file name is the name of the library file that contains the desired 
modules. Libraries must be in SYSSLIBRARY and have the default file 
type TLB. If you do not specify a file name, by default the file name is 
SYS$LIBRARY:SYSDEVCTL.TLB; 1. You can use the /LIBRARY qualifier to 
specify an alternate device control library, for example: 

$ INITIALIZE/QUEUE/LIBRARY=MYDEVCTL ELF.QUE 

Note: If you specify a file name in this parameter, do NOT include the directory, 
file extension, or version number. The system assumes that the file is in 
SYS$LIBRARY and has the extension TLB. If you copy a library file from 
another node, be sure that the new library has a unique file name. 

Operations that request a particular device control library module (by issuing 
the PRINT/SETUP or PRINT/FORM command) use the module from the 
library specified for the queue. If you have a small configuration of printers, 
and normally use only a few modules, you typically store all modules in a 
single library and assign that same library to each printer queue. 

For sites with a large number of different printers, you typically create and 
assign a separate device control library for each printer queue. By using 
separate libraries for each printer queue, you can create modules that have 
the same name and perform the same functions, but contain escape sequences 
unique to the specific type of printer. If you use a single library to store 
modules for different types of printers, you must make sure that each module 
has a unique name. 

You use the following command format to display a listing of all modules 
contained within a specified library: 

LIBRARY/LIST/FULL SYS$LIBRARY:library-name.TLB 

Note: To add or delete a module from a library, you must stop all output queues 
assigned to that library. 


9.7.2.2 Requesting a Library Module 

The system manager can control the printer setups available to users by 
defining forms that are associated with one or more device control library 
modules for a particular queue. The DCL command DEFINE/FORM/SETUP 
associates a form with a device control library module that sets up the printer 
before each file of a job is printed. The command DEFINE/FORM/PAGE_ 
SETUP associates a form with a module that sets up the printer before each 
page is printed. 

By issuing the appropriate PRINT/FORM or PRINT/SETUP command users 
can request a device control module to set up a specific printer option, or to 
insert text at the beginning of each file or at the beginning of each page. 
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The PRINT/FORM command has certain advantages over the PRINT/SETUP 
command. The form name specified with the PRINT/FORM command is 
checked for validity when the command is issued. However, the module 
names are not checked until the file is printed, because the name of the 
device control library is not determined until that time. If a user makes an 
error while entering the module name in the PRINT/SETUP command, the 
job may not print. To reduce the chance of user errors occurring when the 
PRINT/SETUP command is entered, DIGITAL recommends that system 
managers use the DEFINE/FORM/SETUP command to assign a library 
module to a specified form. Once a form is properly defined, then use 
the PRINT/FORM command to set up the printer for the specified printer 
function. 

Warning: If you enter an erroneous module name while issuing the PRINT/SETUP 
command, the print symbiont writes an error message to the output 
device stating that the module does not exist, and the print job fails to 
print and may be lost. By default, jobs are NOT retained in an output 
queue. (See Section 9.5.1 for information on retaining jobs.) 

To reset the printer device to a known state at the end of each job, you use 
the /SEPARATE=RESET qualifier when the queue is initialized, for example: 

$ INITIALIZE/QUEUE/LIBRARY=MYDEVCTL/SEPARATE=RESET=M0DULE2 ELF.QUE 

The RESET keyword sets up the printer according to the reset sequence 
contained in the specified device control module. You can use the 
/SEPARATE=RESET qualifier with the INITIALIZE/QUEUE, START/QUEUE 
or SET QUEUE command. In addition to outputting the RESET sequence at 
the end of each job, the RESET modules are also output when the queue is 
started. This ensures that the first job will be correctly printed. 

Example 9-1 shows a sample session in which device control library modules 
are used to process a print job. In this session, two device control modules 
are created and inserted into the library file MYDEVCTL.TLB, a print job 
(REPORT.TXT) is processed using the MODULE 1 setup, and at the end of the 
job, the printer is reset to the MODULE2 setup. 

Example 9-1 Using Device Control Library Modules to Process 
a Print Job 


$ LIBRARY/CREATE/TEXT SYS$LIBRARY:MYDEVCTL.TLB 
$ CREATE MODULE1.TXT 

tenter printer escape sequences or text for modulel 
ttype CTRL/Z to EXIT 

$ CREATE M0DULE2.TXT 

tenter printer escape sequences or text for module2 
ttype CTRL/Z to EXIT 

$ LIBRARY/INSERT SYS$LIBRARY:MYDEVCLT.TLB/TEXT M0DULE1 
$ LIBRARY/INSERT SYS$LIBRARY:MYDEVCLT.TLB/TEXT M0DULE2 
$ INITIALIZE/QUEUE/START/0N=TTA9/LIBRARY=MYDEVCTL ELF.QUE 
$ SET QUEUE/SEPARATE=RESET=M0DULE2 ELF.QUE 
$ SHOW QUEUE/FULL ELF.QUE 
Terminal queue ELF.QUE, on TOAD::TTA9 

/BASE_PRI0RITY=4 /DEFAULT*(FEED) /FORM*DEFAULT /LIBRARY=MYDEVCTL 
/OWNER*[1,4] /PROTECTION*(S:E,0:D,G:R,W:W) /SEPARATE=RESET=(M0DULE2) 

$ DEFINE/F0RM/SETUP=M0DULE1 F0RM1 1 

$ PRINT/F0RM=F0RM1 REPORT.TXT/QUEUE=ELF_QUE 

Job REPORT (Queue ELF.QUE, entry 619) started on ELF.QUE 

$ 
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9.7.3 Restricting Jobs by Size 

In some cases you may want to restrict print job processing to jobs of a certain 
size. You can impose limits on the size of jobs that can be printed on a queue 
by specifying the /BLOCK_LIMIT qualifier with the INITIALIZE/QUEUE, 
START/QUEUE, or SET QUEUE command. The /BLOCK_LIMIT qualifier 
has the following format: 

/ [NO]BLOCK_LIMIT=([lower][.upper]) 

To impose block size limits, you must specify at least one of the following 
parameters: 


Parameter 

Description 

lowlim 

A decimal number referring to the minimum number of blocks 
that can be scheduled for processing by the queue. If a print job 
is submitted that contains fewer blocks than the lowlim value, 
the job remains pending until the block limit for the queue is 
changed. By default there is no lower limit on job size. 

uplim 

A decimal number referring to the maximum number of blocks 
that can be scheduled for processing by the queue. If a print job 
is submitted that exceeds this value, the job remains pending 
until the block limit for the queue is changed. By default there is 
no upper limit on job size. 


The /BLOCK_LIMIT qualifier is useful when you want to limit processing on 
a queue to either small or large jobs. By default, there are no limits on file 
size for a queue. (For a complete description of the /BLOCK —LIMIT qualifier, 
see the VAX /VMS DCL Dictionary.) 

In the following example, processing on a printer queue LPBO is limited to 
large jobs: 

$ INITIALIZE/QUEUE/ON=LPBO/BLOCK_JLIMIT*(500. M M ) LARGE 

Jobs smaller than 500 blocks will not execute from queue LPBO. It is reserved 
for jobs larger than 500 blocks. 

Warning: If you specify a single value for n in the qualifier /BLOCK_LIMIT=n, the 
value is interpreted as the upper limit for that queue. 


9.7.4 Restricting Jobs by Characteristics 

You can restrict job processing on a queue by assigning specific characteristics 
to the queue. You specify the printer characteristics of an output execution 
queue with the /CHARACTERISTIC qualifier of the INITIALIZE/QUEUE, 
START/QUEUE, or SET QUEUE command. This qualifier can also be used to 
assign characteristics to batch queues. 

When users include the /CHARACTERISTICS qualifier with a PRINT or 
SUBMIT command, the characteristics must by identical or a subset of those 
specified for the queue. However, a queue with no characteristics defined 
will still execute a job that has characteristics specified on the command 
line. For example, if a job is associated with characteristic 25, it can execute 
either in a queue with characteristic 25 or in a queue with no characteristics 
defined. If the characteristics for a job do not match the characteristics 
defined for a queue, the job remains pending until a queue with matching or 
no characteristics becomes available. 
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Note: Users need not specify every characteristic of a queue when they issue a 
PRINT or SUBMIT command, as long as the characteristics specified are a 
subset of those set for the queue. 

To specify the printer characteristics of an output execution queue, use the 
/CHARACTERISTIC qualifier of the INITIALIZE/QUEUE, START/QUEUE, 
or SET QUEUE command in the following format: 

/[NO]CHARACTERISTIC-(characteristic[,...]) 

A characteristic can be a number, a name, or both. You define a characteristic 
name and assign it a corresponding number with the DCL command DEFINE 
/CHARACTERISTIC. This command is restricted to users with OPER 
privilege. Issue the DEFINE/CHARACTERISTIC command in the following 
format: 

DEFINE/CHARACTERISTIC name number 

The following example defines the characteristic name RED_INK and the 
corresponding number 3: 

$ DEFINE/CHARACTERISTIC RED_INK 3 

Subsequent INITIALIZE/QUEUE, START/QUEUE, SET QUEUE, and PRINT 
commands can use the number 3 or the name RED_INK to describe one 
printer characteristic. 

To delete a defined characteristic, issue the DCL command DELETE 
/CHARACTERISTIC, for example: 

$ DELETE/CHARACTERISTIC RED_INK 3 

By default, a queue or job has no characteristics defined. To find out if the 
queues on your system have characteristics defined, issue the DCL command 
SHOW QUEUE/CHARACTERISTICS. 


9.7.5 Restricting Jobs by Form 

A more versatile method of restricting print job processing is by form. A form 
may be defined with the following attributes: width, length, truncate, wrap, 
margin, page setup, form setup, sheet feed, stock, and description. To find 
out what forms are available on your system, issue the DCL command SHOW 
QUEUE/FORM, as shown in this example: 

$ SHOW QUEUE/FORM/FULL 

Form name Number Description 

DEFAULT 0 System-defined default 

/LENGTH=66 /MARGIN*(B0TT0M=6) /STOCK=DEFAULT /TRUNCATE /WIDTH*132 

LN01.P0RTRAIT (stock=DEFAULT) 106 80 by 60 (portrait) 

/LENGTH=60 /SETUP*(LN01_P0RTRAIT) /ST0CK=DEFAULT /WIDTH*80 
LETTER (stock=DEFAULT) 110 LN03 indented memo format 

/LENGTH*64 /MARGIN*(T0P=2,LEFT=5) /STOCK=DEFAULT /TRUNCATE /WIDTH=80 

This command produces a listing of all of the forms available on your system, 
their names, numbers, and associated attributes. 

To restrict print jobs by form, you use the /FORM-MOUNTED qualifier of 
the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command, in the 
following format: 

/F0RM_M0UNTED=type 
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Mounting a form on a queue associates the stock of the form with the output 
queue. Before you mount a form on a queue, you must first define the form, 
using the DEFINE/FORM command. 


9.7.5.1 Defining a Print Form 

You define a form by issuing the DCL command DEFINE/FORM. This 
command is restricted to users with OPER privilege. A form definition can 
include a name, a corresponding number, and optional form characteristics. 
The DEFINE/FORM command uses this format: 

DEFINE/FORM name number [/qualifiers] 

The command in the following example defines the form name CHECKS as 
the number 3 and defines the margins for the form: 

$ DEFINE/FORM=CHECKS 3/ST0CK=DEFAULT - 
_$ /MARGIN=(B0TT0M=3.T0P=3.LEFT=6,RIGHT=6) 

In this example, /FORM=CHECKS is interpreted to be the same as /FORM=3. 
Note that you cannot abbreviate the form name. 

By specifying additional qualifiers with the DEFINE/FORM command, you 
can define the following characteristics for a particular form type: 

• A specific image area for the form 

• A type of paper stock 

• Specific device control modules 

• Print job processing attributes 

The /STOCK qualifier of the DEFINE/FORM command allows you to 
associate a type of paper stock with a particular form. This qualifier is 
useful when you have several forms that use the same paper stock, but differ 
in other ways, such as margin specifications, wrapping, or page dimensions. 

If you do not specify a stock name with the DEFINE/FORM command, the 
form name becomes the default value of the /STOCK qualifier. 

Note: A print job can execute on a queue only if the stock of the form associated 
with the job is identical to the stock of the form mounted on the output 
queue. If the stocks do not match, the job remains pending until they are 
made identical. 

In the following example, the print job would remain pending, because the 
stocks of the two forms are not identical: 

$ DEFINE/FORM=LETTER 5/ST0CK=LQR_36 
$ DEFINE/FORM=MEMO 6/ST0CK=LTH_2 
$ SET QUEUE/FORM_MOUNTED=MEMO PRINT.QUE 
$ PRINT/QUEUE=PRINT_QUE/F0RM=5 MYJ0B.DAT 

In this example, the command PRINT/FORM=5 associates the form type 5, 
with the print job MYJOB.DAT. The stock of the form mounted on the queue 
(form type 6) does not match the stock of the form associated with the job 
(form type 5), therefore the job remains pending until the stock of the two 
forms are made identical. 

To delete a defined form, issue the DCL command DELETE/FORM in the 
format: 

DELETE/FORM form_name 

For a detailed description of the DEFINE/FORM command and its qualifiers, 
see the VAX/VMS DCL Dictionary. 
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9.7.5.2 Changing the Systemwide Default Form 

The VAX/VMS system supplies a systemwide default form named DEFAULT, 
which corresponds to the form number 0. The DEFAULT form has the 
following attributes: 

Form name Number Description 

DEFAULT 0 System-defined default 

/MARGIN®(B0TT0M=6) /STOCK=DEFAULT /TRUNCATE /WIDTH=132 

The default form for both queues and print jobs is form number 0. The stock 
is the system-supplied default stock. To change the systemwide default, issue 
the following command: 

DEFINE/FORM DEFAULT 0 attribute.qualifier[s] 

For example, to change the systemwide default form's bottom margin from 6 
to 4, and the page length from 66 to 55, issue this command: 

$ DEFINE/FORM DEFAULT 0 /MARGIN®(B0TT0M=4) /LENGTH®55 

A queue initialized without a specific /FORM—MOUNTED or 
/DEFAULT=FORM=type qualifier uses the systemwide default form to process 
print jobs not explicitly associated with a form definition. See Section 9.7.7 
for information on how to change the default form for a specific output queue. 


9.7.5.3 Using the PRINT Command to Specify a Form 

In addition to associating forms with specific queues, you can also use the 
PRINT/FORM command to associate a form with a specific job. You must 
define the form type using the DEFINE/FORM command prior to issuing the 
PRINT command. 

When you issue the DCL command PRINT/FORM=type, the print job is 
processed according to the attributes associated with that form. 

Note: The PRINT/FORM=type command overrides the default form established 
for the queue. 

A job submitted without an explicit form definition (that is, the PRINT 
command is issued without the /FORM qualifier) is processed with the 
default form for the queue. (See Section 9.7.7 for information on specifying a 
default form for a queue.) 


9.7.6 Specifying Mandatory Queue Attributes 

You can control certain print job processing attributes by assigning job 
separation features to the queue. Unlike default print control features 
(discussed in Section 9.7.7), job separation features cannot be overridden 
by the PRINT command. 

The three mandatory separation pages include: job burst, job flag, and job 
trailer pages. Most sites will use only a subset of the available separation 
pages at a given time. Figure 9-1 shows the output of typical job flag and job 
burst pages. Figure 9-2 shows the output of a typical trailer page. 

You assign job separation features to a queue by specifying the /SEPARATE 
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE 
command. The /SEPARATE qualifier has the following format: 

/[NO]SEPARATE®(option [,...]) 
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In addition to specifying separation pages, you can also use the /SEPARATE 
qualifier to specify a list of device control library modules. Typically, device 
control library modules are used to reset the device to a known state at the 
end of each job (as previously discussed in Section 9.7.2). 

Figure 9-1 Job Flag and Burst Pages 
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Figure 9-2 Job Trailer Page 
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You assign job separation features by specifying one or more of the following 
options of the /SEPARATE=(option[, . . . ]) qualifier: 


Option Description 

[NOjFLAG Specifies that a job flag page is printed 

at the beginning of each job. 

[NOjBURST Specifies that a job burst page and a job 

flag page are printed at the beginning of 
each job. 

[NO]RESET=(module[, . . . ]) Specifies one or more device control 

library modules that contain the job 
reset sequence for the queue. The 
specified modules from the queue's 
device control library (by default 
SYS$LIBRARY:SYSDEVCTL) are used 
to reset the device each time a job reset 
occurs. The RESET sequence occurs 
after any file trailer and before any job 
trailer. Thus, all job separation pages 
will be printed when the device is in its 
RESET state. 
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Option 

Description 


You should assign the RESET job 
separation feature to queues for printers 
that support characteristics changeable 
by the DCL command PRINT/SETUP. The 
RESET feature ensures that any SETUP 
features specified for a particular job are 
not assigned to the next job. 

[NOjTRAILER 

Specifies that a job trailer page is printed 
at the end of each job. 


By default, no job separation features are assigned to the queue. For more 
information on the /SEPARATE options, see the VAX/VMS DCL Dictionary. 

Widths greater than 40 characters and less than 200 characters, and lengths of 
any size greater than 40 characters are supported for file and job separation 
pages. Pages requested for widths greater than 200 characters are formatted 
and printed at 200-character widths. Lengths less than 40 characters are 
extended by that form length until the 40-character threshold is exceeded. 
Margins are not taken into account when formatting separation pages. 

Note: All separation pages format information to the width and length of a 
VAX/VMS default form size of 80 characters by 51 lines. Information, 
therefore, may be truncated, depending on the form sizes you specify. See 
Section 9.7.8 for information on controlling line and page overflow. 

Table 9-4 gives a detailed description of the characteristics of job separation 
pages. 

Table 9-4 Job Separation Pages 

Page Characteristics 

Job Flag/Burst Indicates that a new job follows; the job may include one 

or more files. Items include: 

• Header bar: single-segment bar composed of the 
following elements: 

- Rows of a repeated numeral indicating the 
sequence of the job in the printer queue 

- An embedded text string specified by defining 
the PSM$ANNOUNCE system logical name. The 
length of the string is limited to one form width. If 
PSMSANNOUNCE is not defined, the default text 
string is "Digital Equipment Corporation" followed 
by the system version number. ("Digital Equipment 
Corporation" is abbreviated to "DEC" for shorter 
form widths.) 
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Table 9-4 (Cont.) Job Separation Pages 

Page Characteristics 

• Note: Users may specify a string up to 255 characters 
in length with the /NOTE qualifier of the DCL command 
PRINT 

• Identification banner for the process submitting the 
job; includes user name, job name, and job number 

• Job sentence indicating the following information: 

- Job name and number 

- Name of queue to which job was submitted 

- Submission date and time 

- Process username, UIC, and account 

- Job priority 

- Print device name 

- Job start time 

- Execution queue name 

• Footer bar: identical to the header bar with the 
exception that the definition of the system logical 
name (PSM$ANNOUNCE) is not used as the embedded 
string. The default text is always used as the 
embedded string. 

Job Trailer Indicates the end of a print job; items include: 

• Header bar: three-segment bar composed of the 
following elements: 

- Central segment with "END OF JOB" banner 

- Flanking segments with job-sequence numeral 

• Identification banner for the process submitting the 
job; includes job name and job number 

• Receipt box with the signoff fields: Received;, Date:, 
and Operator: 

• Job sentence 

• Ruler 


Note: If you request job burst and file burst pages, a separation burst bar (with 
the characters VAX/VMS) is printed over the page crease between the job 
flag and job burst pages, and between the file flag and file burst pages, 
respectively. This facilitates the separation of job and file printouts. 
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9.7.7 Specifying Default Queue Attributes 

You can control the default processing attributes of a queue by specifying the 
/DEFAULT qualifier of the INITIALIZE/QUEUE, START/QUEUE, or SET 
QUEUE command. For example, you can establish a default form type for a 
specific queue, and specify the default file separation pages. The /DEFAULT 
qualifier has the following format: 

/[NO]DEFAULT=(option[,...]) 

The following default options are available: 


Option 

Description 

[NO]BURST[=value] 

Controls whether a file flag and burst page is 
printed preceding output. If you specify the value 
ONE, a flag and burst page is printed once with the 
first file in the job. If you specify the value ALL, a 
flag and burst page is printed with each file in the 
job. 

[NO]FEED 

Controls whether a form feed is automatically 
inserted at the end of a page. 

[NO]FLAG[=value] 

Controls whether a file flag page is printed 
preceding output. If you specify the value ONE, a 
flag page is printed once with the first file in the 
job. If you specify the value ALL, a flag page is 
printed with each file in the job. 

FORM=type 

Specifies the default form for a printer, terminal, 
or server queue. If a job is not submitted with an 
explicit form definition, then this form will be used 
to process the job. The systemwide default form 
(DEFAULT,0) is the default value for this keyword. 

[NO]TRAILER[=value] 

Controls whether a file trailer page is printed 
following output. If you specify the value ONE, a 
trailer page is printed once with the last file in the 
job. If you specify the value ALL, a trailer page is 
printed with each file in the job. 


The value ALL is the default value for options that require a value of ALL 
or ONE. Figure 9-3 shows the output of typical file flag and file burst pages. 
Figure 9-4 shows the output of a typical file trailer page. 
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Figure 9—3 File Flag and Burst Pages 
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Figure 9—4 File Trailer Page 
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Table 9-5 gives a detailed description of the characteristics of file separation 
pages. 
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Table 9-5 File Separation Pages 

Page Characteristics 

File Flag/Burst Indicates that a print file follows. The file may include one 

or more of the following items: 

• Header bar: three-segment bar composed of the 
following elements: 

- A central segment identical to the job header bar 

- Flanking segments with rows of a repeated 
character indicating the sequence of the file in 
the job 

• Note: Users may specify a string up to 255 characters 
in length using the /NOTE qualifier of the DCL 
command PRINT 

• Identification banner for the process submitting the 
job: user name, file name 

• File sentence: indicates the following information: 

- Full file specification, including device and 
directory, file name, type, version, and revision 
time and date 

- File size in blocks 

- File organization 

- File owner's UIC 

- File record characteristics: record type, carriage 
control, size of longest record 

• Job sentence 

• Footer bar: identical to header bar except that the 
embedded text string is "Digital Equipment Corporation 

- Version Vn.n" 
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Table 9-5 (Cont.) File Separation Pages 


Page 

Characteristics 

File Trailer 

Indicates the end of a print file. Items include: 


• 

Header bar: five-segment bar composed of the 
following elements: 

- Central segment with "END OF FILE" banner 

- Inner flanking segments with job-sequence numeral 

- Outer flanking segments with file-sequence 
character 


• 

Identification banner for the process submitting the 
job; includes user name, file name 


• 

Qualifier phrase: indicates the print, queue, and 
form qualifiers active when the job was submitted; 
nonactive qualifiers (except /NORECORD_BLOCKING 
and /NOFEED) are not included 


• 

File sentence 


• 

Job sentence 


• 

Footer bar identical to file flag/file burst footer bar 


• 

Ruler: a sequence of numbers counting to the end of 
the form 


You can change the default form type for a specific output queue by using the 
/DEFAULT=FORM=type option of the DCL command INITIALIZE/QUEUE, 
START/QUEUE, or SET QUEUE. The new default form must first be defined 
using the DEFINE/FORM=type command. The stock of the default form must 
be identical to the stock of the mounted form, or any job submitted without 
an explicit form will enter a pending state until they are made identical. 

To find out the default form for a particular queue, issue the DCL command 
SFiOW QUEUE/FULL, as shown in this example: 

$ SHOW QUEUE/FULL LN01.PRINT 

Printer queue LN01.PRINT, on ALPHA::ALPHA_LCAO, mounted form STANDARD (stock=8xll) 
/BASE_PRI0RITY=4 /DEFAULT 3 (FEED.FLAG.FORM=REPORT(stock 3 8xl1).TRAILER=ONE) 
/NOENABLE.GENERIC Lowercase /OWNER 3 [1,4] /PROTECTION 3 (S:E,0:D.G:R,W:W) 

In this example, the default form is named REPORT and the stock is named 
8x11. The stock of the default form matches the stock of the mounted form. 
All jobs not associated with an explicit form definition will be associated with 
the form named REPORT by default. Since the stock of the form STANDARD 
matches the stock of the default form REPORT, all jobs submitted to this 
queue without an explicit form definition will be processed. 
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9.7.8 Controlling Page and Line Overflow 

You can use form definitions to control page and line overflow. Different 
forms may have different right, left, top, and bottom margin settings. By 
using forms to control page and line overflow, users can switch from one 
form to another without requiring operators to stop the queue, alter the 
device setup, and restart the queue. Forms with the same value for the 
/STOCK qualifier are automatically mountable without operator assistance. 
You control line overflow by using the following qualifiers to the DCL 
command DEFINE/FORM: 


Qualifier 

Function 

/[NOJTRUNCATE 

Specifies that data in the right margin be discarded. The 
default is /TRUNCATE. If you specify /TRUNCATE, you 
cannot specify /WRAP; the /TRUNCATE qualifier forces 
/NOWRAP. 

/[NOJWRAP 

Specifies that a carriage return and line feed be inserted 
when the right margin is exceeded. The default is 
/NOWRAP. If you specify /WRAP, you cannot specify 
/NOTRUNCATE. 


Page overflow errors are handled by the /DEFAULT=FEED option of the 
following commands: 

INITIALIZE/QUEUE 
START/QUEUE 
SET QUEUE 
PRINT/[NO]FEED 

This qualifier controls whether a formfeed character is automatically inserted 
when the symbiont detects entry into the bottom margin area. 

DIGITAL recommends that you control line and page overflow by using form 
definitions. To do this, you must set terminals and printers to avoid wrapping 
or truncating the print line at the physical limits of the device. 

Note: The device driver operates on settings for the /TRUNCATE and /WRAP 
qualifiers specified with the DCL commands SET PRINTER and SET 
TERMINAL only after the print symbiont has finished formatting data. 

You can use the /PASSALL qualifier with the PRINT command to bypass all 
formatting performed by the print symbiont. The default is /NOP ASS ALL. 
You should use this qualifier in cases where the print symbiont formatting 
may interfere with the desired formatting of the file. The /PASSALL qualifier 
sends I/O to the device driver with all formatting suppressed, and behaves as 
follows: 

• Does not interpret FORTRAN or print carriage control characters 

• Does not perform line or page overflow error handling 

• Does not interpret escape sequences 
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9.7.9 Setting Up Logical Queues 

A logical queue performs the same function as a generic output queue, except 
that a logical queue can direct jobs only to a single printer, terminal, or server 
execution queue. Jobs sent to a logical queue are held until the logical queue 
is assigned to an output execution queue and both queues are started. Logical 
queues can be used, for example, to hold print jobs of low-priority users for 
printing during off-peak hours. 

You assign a logical queue to an output execution queue with the DCL 
command ASSIGN/QUEUE. This command is restricted to users with OPER 
privilege or E access to the queues. 

Inserted in a command procedure, the following commands initialize and start 
the printer queue LPAO and initialize the logical queue named HOLD_QUE: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO: 

$ INITIALIZE/QUEUE HOLD_QUE 

Jobs sent to the printer queue LPAO are queued for printing. However, any 
jobs sent to the logical queue HOLD_QUE are held until HOLD_QUE is 
assigned to LPAO and started (normally from command level) as follows: 

$ ASSIGN/QUEUE LPAO: HOLD.QUE 
$ START/QUEUE HOLD.QUE 

To deassign the logical queue in the example above, use the following 
procedure: 

1 Stop the logical queue by specifying the STOP/QUEUE/NEXT command. 

2 Deassign the logical queue by specifying the DCL command 
DEASSIGN/QUEUE. 

The following commands deassign the logical queue HOLD_QUE: 

$ STOP/QUEUE/NEXT H0LD_QUE 
$ DEASSIGN/QUEUE HOLD.QUE 

The VAX/VMS DCL Dictionary describes the DEASSIGN/QUEUE command 
in detail. 


9.7.10 Setting Up Generic Output Queues 

When print jobs are sent to a generic output queue, they are held there until 
one of the assigned printer or terminal queues becomes available. Generic 
output queues are useful because they distribute the processing of print jobs 
among devices that are of the same type. Figure 9-5 illustrates a generic 
output queue. 
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Figure 9-5 Generic Output Queue 
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If your system has more than one line printer of the same type, you should 
create at least one generic output queue. Since print jobs submitted with the 
PRINT command are sent to the queue SYS$PRINT by default, you should 
establish SYS$PRINT as a generic queue, assigning to it printers that perform 
basic print operations. 

You establish a generic queue by specifying the /GENERIC qualifier with 
either the INITIALIZE/QUEUE or START/QUEUE command. See the 
VAX/VMS DCL Dictionary for a description of how the /GENERIC qualifier is 
used with these commands. 

Note: The /DEFAULT, /FORM-MOUNTED, and /SEPARATE qualifiers 

are not meaningful for generic output queues. Consequently, the DCL 
commands INITIALIZE/QUEUE and START/QUEUE will reject these 
qualifiers if /GENERIC is also specified. If the attributes of an established 
generic output queue are modified, these three qualifiers may be accepted. 
However, they have no effect on the operation of the generic queue. 

With the /GENERIC qualifier, you can assign a printer queue to a generic 
output queue by one of the following methods: 

• Default —Using this method, you do not specify a queue name parameter. 
Instead, any output execution queue that has generic printing enabled and 
is of the same type (either printer, terminal, or server) is assigned to the 
generic output queue by default. 

• Explicit —With this method, you specify the name of an output execution 
queue (either printer or terminal) as a parameter. 
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9.7.10.1 Assigning Generic Output Queues by Default 

On systems with a small number of printers, you should use the default 
function of the /GENERIC qualifier to establish a generic output queue. With 
this method, you specify the /GENERIC qualifier without specifying any 
queue name parameters, and all output execution queues that are enabled for 
generic printing are assigned to the generic output queue. 

Output execution queues are enabled for generic printing by default when 
they are initialized. 

Note: Output execution queues for line printers that are in remote locations, 
that use special forms, or that possess unique printer characteristics 
should be set up with generic printing DISABLED, to exclude them from 
accepting jobs from a generic output queue. 

The qualifier /NOENABLE—GENERIC, when used with the INITIALIZE 
/QUEUE, START/QUEUE, or SET QUEUE commands, disables generic 
printing on an output execution queue. 

The following command procedure creates four different printer queues, 
including a generic output queue: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO: 

$ INITIALIZE/QUEUE/START/NOENABLE.GENERIC LPCO: 

$ INITIALIZE/QUEUE/START/GENERIC SYS$PRINT 

In this procedure, since no queue names were specified with the /GENERIC 
qualifier, only the queues that have generic printing enabled by default, LPAO 
and LPBO, are assigned to the generic queue SYS$PRINT. The queue LPCO is 
not assigned to the generic output queue because generic printing is explicitly 
disabled. 

There is no advantage to creating more than one generic output queue by 
using the default method, since all printer queues with generic printing 
enabled are assigned to the generic queue. Again, on systems with only a 
few printers that are of the same type, the default method is adequate. On 
larger systems with many different types of printers, the default method is 
not recommended. 

Using the default method, you can assign to a generic queue only one type of 
output execution queue, either printer queues or terminal queues, not both. 

To establish a generic terminal queue, specify the /TERMINAL qualifier 
along with the /GENERIC qualifier. If you want to set up a generic output 
queue that serves both printer and terminal queues, you must use the explicit 
assignment method described in the next section. 


9.7.10.2 Assigning Generic Output Queues Explicitly 

On systems with a large number of printers of many different types, you 
should explicitly assign printer queues to a generic output queue using the 
/GENERIC qualifier. The /GENERIC qualifier accepts a list of the queues. 
The following command procedure creates four different printer queues, 
including a generic output queue: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO: 

$ INITIALIZE/QUEUE/START/DEFAULT=(FLAG.TRAILER.NOFEED) LPCO: 

$ INITIALIZE/QUEUE/START/GENERIC=(LPAO:.LPBO:) SYSIPRINT 
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In this procedure, the printer queues LPAO and LPBO are assigned to the 
generic output queue SYS$PRINT. The printer assigned to LPCO uses special 
forms and is not suited for general printing. Therefore, it is not assigned 
to the generic output queue SYS$PRINT. Print files queued by default to 
SYS$PRINT are printed on whichever assigned printer (either LPAO or LPBO) 
is free. 

By specifying a list of queue names with the /GENERIC qualifier, you can 
assign printer queues, terminal queues, or both to a generic output queue. 
This method also allows you to create more than one generic output queue. 
For example, you may want to create a separate generic output queue for each 
set of printers having similar characteristics: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPCO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG TTD5 
$ INITIALIZE/QUEUE/START/GENERIC=(LPAO:.LPBO:) SYS$PRINT 
$ INITIALIZE/QUEUE/START/GENERIC-(LPCO:,TTD5) SMALLFORM 

This command procedure creates two generic output queues, SYS$PRINT 
for routine print jobs, and SMALLFORM for print jobs requiring special size 
forms. Here it is assumed that printer queues LPCO and TTD5 are set up for 
special form jobs. 


9.7.11 Setting Up Spooled Devices 

Spooling is the technique of using an intermediate storage device (such as a 
disk) to buffer data passing between low-speed I/O devices and high-speed 
memory. Establishing spooled devices is useful for increasing throughput and 
balancing the I/O demands of a system. As a rule, programs demand input 
and produce output at irregular intervals during their execution. If programs 
were allowed to read directly from fast devices and to write directly to slow 
devices, the throughput would be limited by the speed of the slow devices. If 
a process were to output data directly to a printer, the process would be tied 
up for the time it took to print the listing. Also, other processes needing the 
printer would have to wait until the current process completed. 

Output spooling makes output from the processor available for transmission 
to a spooled device (such as a line printer) by placing the output into files 
on an intermediate device (such as a disk). Output spooling is used to create 
temporary files on disk. After they are spooled to disk, these files are queued 
for printing. 

Note: On a system with both spooled input devices and spooled output devices, 
you must create and start at least one batch queue to handle spooled 
input, and one output queue to handle spooled output. 

You establish a printer as a spooled device by using the DCL command SET 
DEVICE/SPOOLED in the following format: 

SET DEVICE/SPOOLED[=(queue-name[:].intermediate-disk-name[:])] 

This command is restricted to users with the OPER privilege. The VAX/VMS 
DCL Dictionary describes the SET DEVICE command in detail. For each 
output spooled device, you can use the SET DEVICE command to specify 
both the printer queue to which spooled files are queued and an intermediate 
device to which spooled files are written. By default, the queue name is 
the same as the printer device name. The intermediate device name is the 
translation of the logical name SYS$DISK. The name is translated when you 
issue the command SET DEVICE/SPOOLED. 
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You should always specify the intermediate disk and queue explicitly. 
Whenever a file is copied to a spooled device, it is queued for printing on 
the queue specified by the SET DEVICE command when the file is closed. If 
you assign a spooled device to a generic queue, a job output to that device is 
sent to the generic queue, which in turn places the job in one of its assigned 
queues. As a result, a job copied to LPAO, for example, may not necessarily 
print on the printer LPAO, but instead may print on one of the other devices 
assigned to the generic queue. 

Note: When you select an intermediate device, ensure that it has sufficient free 
space for the volume of queued output you expect. If you plan to enforce 
disk quotas on the intermediate device, ensure that all expected users of 
the spooled device have a quota authorized on the intermediate device. 

The following example gives the steps for setting up a typical spooled device 
configuration for a system with one line printer: 

$ SET PRINTER/LOWER LPAO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPAO: SYS$PRINT 

(See Section 9.7.12.1 for more information on setting up a single-printer 
configuration.) 

Caution: After establishing a device as spooled, you should test the device, 

since errors in disk or queue names are not detected until spooling is 
attempted. To test a spooled device, use a command procedure similar to 
the following: 

j *****testing spooled device*** 

$ SET DEVICE/SPOOLED=(SYSlPRINT,SYS$SYSDEVICE:) LPAO: 

$ CREATE TEST.LIS 

!Add the first test record here. 

!CTRL/Z to exit the file 
$ COPY TEST.LIS LPAO: 

$ EXIT 

You set up devices for spooling by entering the appropriate commands in 
your site-specific command procedure (SYSTARTUP.COM). At a minimum, 
you should see that at least one line printer is set spooled when the system 
is booted. In a system with only one line printer, the spooled printer will 
be the default system printer. Depending on system configuration and 
anticipated operational needs, more spooled devices can be established at 
startup. Moreover, in the course of operations (to meet special needs), you 
can define still other devices as spooled devices without having to reboot the 
system. Normally, all line printers should be spooled. 

You can, as necessary, use the SET DEVICE command with the 
/NOSPOOLING qualifier to disable spooling to spooled printers and 
terminals; however, you must stop the corresponding queues before you 
can change the spooling status. 
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9.7.12 Guidelines for Setting Up Queues for Spooled Line Printers 

The guidelines in this section apply to line printers in a single-node 
environment. In a cluster environment, clusterwide queues are established 
to control print job processing. The Guide to VAXclusters provides a detailed 
description of how to set up printer queues for line printers in a cluster 
environment. 

The following guidelines are useful in setting up printer queues for spooled 
line printers and terminals used as printers: 

• Specify the proper characteristics for each printer with the DCL command 
SET PRINTER. (The VAX/VMS DCL Dictionary describes the SET 
PRINTER command in detail.) 

• Control line overflow with the /TRUNCATE and /WRAP qualifiers of 
the DCL command DEFINE/FORM. The form controls the line and page 
overflow, therefore, set the printer or terminal width and length to the 
physical limits of the device. (See Section 9.7.8 for more information on 
these qualifiers.) 

• Spool the device with the DCL command SET DEVICE/SPOOLED. 

• To produce output on a spooled line printer, initialize a printer queue with 
the same name as the spooled printer and start that queue. You can also 
assign a queue a name that is different from the printer's physical device 
name by using the /ON qualifier with the INITIALIZE command (see 
Section 9.7.1). 

• Assign one printer queue the name SYS$PRINT. For systems with one 
printer, assign that printer's queue the name SYS$PRINT. If more than 
one line printer is on the system, make at least one printer queue a generic 
queue and assign it the name SYS$PRINT. Section 9.7.10 describes how 
to establish generic output queues. 

The next three sections illustrate some of the most common arrangements of 
output execution queues and spooled line printers. 


9.7.12.1 Single-Printer Configuration 

Figure 9-6 illustrates a typical spooling and queuing configuration for a 
system with one line printer. The following commands in your site-specific 
SYSTARTUP.COM procedure produce the results listed below: 

$ SET PRINTER/LOWER LPAO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPAO: SYSlPRINT 

1 The characteristics of LPAO are set. 

2 The line printer LPAO is set spooled. 

3 A printer queue for LPAO is initialized, started, and assigned the name 
SYS$PRINT. 

4 All print jobs are placed by default in a queue named SYS$PRINT and are 
printed from that queue. 
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Figure 9-6 Setting Up a Printer Queue on a System with One 
Printer 
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9.7.12.2 Two-Printer Configuration 

Figure 9-7 illustrates a typical spooling and queuing configuration for 
a system with two line printers that have the same characteristics. The 
following commands produce the results listed below: 

$ ! 

$ ! Set printer characteristics, set LPAO spooled, 

$ ! and set up queue PRINT.A. 

$ ! 

$ SET PRINTER/LOWER LPAO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPAO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPAO: PRINT.A 

$ ! 

$ ! Set printer characteristics, set LPBO spooled, 

$ ! and set up queue PRINT_B. 

$ ! 

$ SET PRINTER/LOWER LPBO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPBO: 

$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPBO: PRINT.B 

$ ! 

$ ! Set up the generic queue SYS$PRINT 

$ ! 

$ INITIALIZE/QUEUE/START/GENERIC SYS$PRINT 

1 The characteristics of device LPAO are set. 

2 The line printer LPAO is set spooled. 

3 The printer queue PRINT__A is initialized and started. 

4 The characteristics of device LPBO are set. 

5 The line printer LPBO is set spooled. 

6 The printer queue PRINT—B is initialized and started. 

7 The generic queue SYS$PRINT is initialized and started and assigned the 
printer queues PRINT_A and PRINT_B by default (see Section 9.7.10.1). 
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8 Print jobs sent with an explicit queue name entered in the PRINT 
command line are placed in the queue for the specific printer. 

9 Print jobs sent without specifying a queue name in the PRINT command 
are placed by default in the generic queue SYS$PRINT. Jobs are then 
scheduled for processing in PRINT_A or PRINT_B, depending on which 
print device is available. 

1 0 Spooled print files destined for either device LPAO or LPBO are placed 
in the generic queue SYS$PRINT, which is associated with both printers. 
From the generic queue, these jobs are printed on whichever printer is 
available. (Alternatively, you could set the devices spooled and assign 
each device the queue name that is associated with that device, thus 
ensuring that jobs will print on the same printer to which the file was 
spooled.) 

Figure 9-7 Setting Up Printer Queues on a System with Two 
Printers 
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9.7.12.3 Three-Printer Configuration 

Figure 9-8 illustrates a typical spooling and queuing configuration for a 
system with three line printers: two that have the same characteristics and 
one that uses special forms, has unique printer characteristics, or is in a 
remote location. The configuration shown in Figure 9-8 is basically the same 
as the one in Figure 9-7, except that the spooled printer LPCO has been 
added and queue PRINT—C has been initialized and started. Because of the 
special forms, unique characteristics, or the remote location, printer LPCO is 
not suited for general printing. Thus, the following commands produce the 
same results as those listed in Figure 9-7, with noted exceptions: 

$ • 

$ ! Set printer characteristics, set LPAO spooled, 

$ ! and set up queue PRINT_A. 

$ ! 

$ SET PRINTER/LOWER LPAO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPAO: 

$ INITIALIZE/QUEUE/DEFAULT=FLAG/START/ON*LPAO: PRINT_A 

$ ! 

$ ! Set printer characteristics, set LPBO spooled, 

$ ! and set up queue PRINT_B. 

$ ! 

$ SET PRINTER/LOWER LPBO: 

$ SET DEVICE/SPOOLED=SYS$PRINT LPBO: 

$ INITIALIZE/QUEUE/DEFAULT=FLAG/START/ON=LPBO: PRINT.B 

$ ! 

$ ! Set printer characteristics, set LPCO spooled, 

$ ! and set up queue PRINT.C with generic queuing disabled. 

$ ! 

$ SET PRINTER/L0WER/PAGE=32 LPCO: 

$ SET DEVICE/SPOOLED=LPCO LPCO: 

$ INITIALIZE/QUEUE/DEFAULT=FLAG/NOENABLE_GENERIC/START/ON-LPCO: PRINT.C 

$ ! 

$ ! Set up the generic printer queue SYS$PRINT 

$ • 

$ INITIALIZE/QUEUE/GENERIC/START SYS$PRINT 

1 The characteristics for LPCO are set. 

2 The line printer LPCO is set spooled. 

3 The printer queue PRINT_C is initialized and started with generic printing 
disabled. 

4 Only print jobs explicitly directed to the printer LPCO or queue PRINT_C 
are placed in PRINT_C. No print jobs are directed to PRINT_C from the 
generic queue SYS$PRINT. 
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Figure 9-8 Setting Up Printer Queues on a System with Three 
Printers 


COMMANDS 


$ SET DEUICE/SPOOLED=SYS$PRINT LPAO 
$ SET DEUICE/SPOOLED=SYS$PRINT LPBO 
$ SET DEUICE/SPOOLED=LPCO LPCO 
$ INITIALIZE/QUEUE/FLAG/GENERIC SYS$PRINT 
$ START/'QUEUE SYS$PRINT 
$ INITIALIZE/QUEUE/FLAG LPAO 
$ START/QUEUE LPAO 
$ INITIALIZE/QUEUE/FLAG LPBO 
$ START/QUEUE LPBO 

$ INITIALIZE/QUE LI E/FLAG/NOENABLE._GENERIC_PRINTING LPCO 
$ START/QUEUE LPCO 


Queues 


SYSSPRINT 

Generic Print 
Queue 


LPAO 

Generic Printing 
Enabled 


LPBO 

Generic Printing 
Enabled 


LPCO 

No Generic 
Printing 


Line Printers 



LPAO 



LPBO 



LPCO 

ZK-1007-82 


9-52 














































Using the Batch/Print Facility 


9.8 Managing the Card Reader 

Information in this section applies to the DIGITAL CR-11 card reader. Note 
that other card readers may function differently. The card reader is used to 
read card decks. Users may submit the two following types of card decks for 
processing: 

• Batch job card decks 

• Data card decks 

To ensure that card decks are processed efficiently, you must understand their 
characteristics and the use of the card reader. The following sections describe 
which cards you should check before processing a deck through a card reader 
and how to determine which cards are damaged. Section 9.8.3.2 outlines a 
procedure for processing a card deck through the card reader. 


9.8.1 Distinguishing the Type of Card Deck 

Before loading a card deck into the card reader, you should determine: 

• Whether the deck is a batch job or a data deck, because their processing 
requirements differ 

• Whether the card reader is set to the correct translation mode 
The following sections describe how to make these determinations. 


9.8.1.1 Batch Job Card Deck 

A batch job card deck consists of three segments: 

• The initial cards 

• The program cards 

• The last card 

The initial two cards in a batch job card deck are the $JOB and the 
$PASSWORD cards. These cards log in the user and the batch job to the 
system. Following the initial two cards are program cards. Program cards 
contain instructions that direct the system to libraries, routines, and data 
needed to complete the batch job. The last card must be either an end-of-job 
command ($EOJ) card or an end-of-file (EOF) card. Either of these cards tells 
the system that this is the end of the job. 

Note: For more information on card reader batch jobs from a system user's 

viewpoint, refer to the Guide to Using DCL and Command Procedures on 
VAX/VMS. 

Checking Input 

The system cannot execute the job without $JOB and $PASSWORD cards. If 
you are given a card deck with these cards omitted, you should return the 
deck so that the user can insert them. 

Since the card deck contains the user's password, you must ensure that it is 
always handled with care to preserve the security of the user's account. 

The last card in the deck must be either an $EOJ or an EOF card. 
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If the last card is not one of these end cards, you can type an end card on the 
card punch (12-11-0-1-6-7-8-9 overpunch in column 1) and place it at the end 
of the deck. 

Checking Output 

The log file produced by a card reader batch job is queued for printing to 
the default system printer queue, SYS$PRINT. To have the log file queued to 
a different queue, the user can specify the /PRINTER qualifier on the $JOB 
card. 

If an error occurs while the system is attempting to validate the $JOB and 
$PASSWORD cards, OPCOM sends to the card operator an error message 
that reports the job card and the error. 


9.8.1.2 Data Card Deck 

A data deck contains data that will be either read by a program or copied 
to a file for later use. The process that will read the data deck is usually 
associated with an interactive user at a terminal, or else with a batch job that 
is submitted by an interactive user. Since the user and process already are 
logged in to the system, the first card can contain any data the user wants 
to specify. Then, either the program must read the exact number of cards 
supplied, or the last card should be an EOF card to inform the program that 
this is the end of the data deck. 

When a user wants a data deck to be read, you should ensure that the user 
has allocated the card reader. If the card reader is not allocated, the system 
tries to submit the deck as a batch job and subsequently just flushes the deck 
through the reader, rejecting the job. 

If the program does not read the exact number of cards (as with the COPY 
command), the EOF card must be the last card in the deck, to inform the 
program that this is the end of the deck. Without this card, the program 
waits indefinitely for more cards, and the system prints "card reader offline" 
messages on the operator's terminal. If the card deck lacks an EOF card, you 
can type one on a card punch and insert it at the end of the deck. 


9.8.2 Setting Card Reader Translation Modes 

For the system to read input properly, the card reader must be set to the 
correct translation mode—the same as the translation mode of the card punch 
used to prepare the deck. The VAX/VMS system supports 026 and 029 card 
punches. (Translation modes are discussed in detail in the VAX/VMS I/O 
Reference Volume and the Guide to Using DCL and Command Procedures on 
VAX/VMS.) 

Therefore, these conditions must exist for you to be able to set the card reader 
to the correct translation mode: 

• The first card in the deck must be the translation mode card. 

• You must know the mode in which the cards were punched. 

To set the translation mode of the card reader for many decks of the same 
type, use the SET CARD-READER command. See the VAX/VMS DCL 
Dictionary for more information on the SET CARD—READER command. By 
default, when the system is bootstrapped, the translation mode is set to 029. 
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9.8.3 Tending the Card Reader 

This section describes how to tend the DIGITAL CR-11 card reader. The job 
of tending the card reader includes: 

• Replacing physically defective cards 

• Operating the card reader 


9.8.3.1 Replacing Physically Defective Cards 

Even when the card deck contains all the required cards, the card reader may 
not be able to read the deck. This problem is usually caused by one or more 
physically defective cards. 

If the deck contains a faulty card, one of the error indicators located on the 
front panel of the card reader lights up when the card is read. The card 
reader goes offline, and operator intervention is required to put it back online. 
Table 9-6 lists the error indicators, the reasons why they may light up, and 
the operator action required to correct the situation. 


9.8.3.2 Operating the Card Reader 

The following steps describe how to load and process a card deck through a 
card reader. 

1 Remove the card weight from the input hopper. Place the cards, face 
down and with column 1 on the left, in the hopper. Ensure that the first 
card to be read is at the bottom of the hopper. 

Do not pack the input hopper so full that the air from the blower cannot 
riffle the cards. If the cards are packed too tightly, the vacuum picker 
cannot operate properly. 

2 Press the RESET button. The HOPPER CHECK error indicator and the 
STOP light will go out and the cards will be read. 

If the card deck is too large to fit in the input hopper, you can load the 
excess cards while the reader is operating if you maintain tension on the 
front portion of the deck. 

3 Remove the cards from the output stacker when either the HOPPER 
CHECK error indicator or the STOP light is lit. 

If you accidentally press the STOP button while the card deck is being 
read, return the last card in the output hopper to the bottom of the input 
hopper and press the RESET button. 

4 If the cards are not read properly after the RESET button has been 
pressed, refer to Table 9-6 for recovery procedures. 
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Table 9-6 Card Reader Errors: Causes and Corrective Actions 


Error 

Causes 

Corrective Action 

READ CHECK 

Card edges torn 

Punch in column 0 or 81 

Remove the faulty card from the output stacker, 
duplicate the card, place it in the input hopper, and 
press the RESET button. 

If READ CHECK occurs for all cards, the read logic of 
the card reader is malfunctioning. 

PICK CHECK 

Damage to leading edge 

Torn webs 

Cards stapled together 

Remove the card from the input hopper, duplicate the 
faulty card, place the card back in the input hopper, 
and press the RESET button. 

If there is no evidence of card damage, check for 
excessive warping of the card deck and/or a buildup 
of ink glaze on the picker face. 

STACK CHECK 

Jam in the card track 

Badly mutilated card 

Correct the jam and/or remove the mutilated card 
from the output stacker, duplicate the card, place it in 
the input hopper, and press the RESET button. 

HOPPER CHECK 

Input hopper empty 

Output stacker full 

Load the input hopper. 

Unload the output stacker. 


9.8.4 Running the Input Symbiont Interactively 

You can run the input symbiont interactively, taking card image input from a 
VAX RMS file by issuing the following commands: 

$ DEFINE/USER SYSSINPUT filename 
$ RUN SYS$SYSTEM:INPSMB 

Running the input symbiont interactively requires the following: 

• CMKRNL privilege 

• Read access to the UAF 

• Write access to the default directory of the user 

All messages are issued to the terminal instead of the card operator. 
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10.1 




The system provides several tools for recording and reporting errors and other 
system events. These tools include facilities for 

• Logging and reporting system events 

• Logging operator messages 

• Handling user requests 

• Reporting problems to DIGITAL 

In the event of a severe system failure, VAX/VMS automatically shuts down 
the system and produces a crash dump of the state of the system at the time 
the error was detected. You can analyze the dump to help you determine the 
cause of the system failure. (For more information, see the VAX/VMS System 
Dump Analyzer Reference Manual.) In a few cases, as described in Section 10.4, 
you may want to forward the dump to DIGITAL with a Software Performance 
Report. 


Error Logging Operations 

The system automatically writes error messages to the latest version of a file 
named SYS$ERRORLOG:ERRLOG.SYS. You can display the information 
in this file by issuing the DCL command ANALYZE/ERROR—LOG. This 
command is described in the VAX/VMS DCL Dictionary. 

The Error Logging Facility consists of three parts: 

1 A set of executive routines that detect errors and events and write relevant 
information into error log buffers in memory 

2 A process called ERRFMT, which periodically empties the error log buffers, 
transforms the descriptions of the errors into standard formats, and stores 
the formatted information in a file on the system disk 

3 The Analyze/Error_Log Utility, activated by the DCL command 
ANALYZE/ERROR_LOG, which you use to report selectively the 
contents of an error log file (see the VAX/VMS Error Log Utility Reference 
Manual) 

The executive routines and the ERRFMT process operate continuously without 
user intervention. The routines fill the error log buffers in memory with raw 
data on every detected error and event. When one of the available buffers 
becomes full, or when a time allotment expires, ERRFMT automatically writes 
the buffers to ERRLOG.SYS. 

Sometimes a burst of errors can cause the buffer to fill up before ERRFMT 
can empty them. You can detect this condition by noting a skip in the error 
sequence number of the records reported in the error log reports. As soon 
as ERRFMT frees the buffer space, the executive routines resume preserving 
error information in the buffers. 
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The ERRFMT process displays an error message on the system console and 
deletes itself if it encounters excessive errors while writing the error log file. 
You can restart ERRFMT (you must have the DETACH privilege) by invoking 
the startup command procedure in the [SYSEXE] directory and by specifying 
the parameter ERRFMT as follows: 

$ <DSYS$SYSTEM: STARTUP ERRFMT 

Invoke the command procedure from tne system manager's account. 


10.1.1 Using Error Reports 

The error reports generated by the Analyze/Error_Log Utility are useful in 
two basic ways: 

1 They aid preventive maintenance by identifying areas within the system 
that show potential for failure. 

2 They aid the diagnosis of a failure by documenting the errors and events 
that led up to it. 

The detailed contents of the reports are most meaningful to DIGITAL field 
service personnel. However, you can use the reports as an important indicator 
of the system's reliability. For example, using the DCL command SHOW 
ERROR, you may see that a particular device is producing a relatively 
high number of errors. You can then use the Error_Log Utility to obtain 
a more detailed report and decide whether you should consult DIGITAL Field 
Service. In that case, field service personnel can run diagnostic programs to 
investigate the device and attempt to isolate the source of the errors. 

In the event a system component does fail, a Field Service representative 
can study the error reports of the system activity leading up to and including 
the failure. For example, if a device fails, you can generate error reports 
immediately after the failure. One report might describe in detail all errors 
associated with the device that occurred within the last 24 hours; another 
report might summarize all types of errors for all devices that occurred within 
the same time period. The summary report can put the device errors into 
a systemwide context. The Field Service representative can then run the 
appropriate diagnostic program for a thorough analysis of the failed device. 
Using the combined error logging and diagnostic information, the Field 
Service representative can proceed to correct the device. 

Error reports allow you to anticipate potential failures. In turn. Field Service 
personnel rely on the reports as an aid to both preventive and corrective 
maintenance. Overall, effective use of the Error Log Utility in conjunction 
with diagnostic programs can significantly reduce the amount of system 
downtime. 


10.1.2 Maintaining the Error Log Files 

Since the error log file, SYS$ERRORLOG:ERRLOG.SYS, is a shared file, 
ERRFMT can write new error log entries while other entries in the same file 
are being read and reported by the Error Log Utility. 

ERRLOG.SYS will increase in size and remain on the system disk until it is 
explicitly renamed or deleted. Therefore, you must devise a plan for regular 
maintenance of the error log file. 
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One method is to rename ERRLOG.SYS on a daily basis. This action 
causes a new error log file to be created and allows the old file (which 
was renamed) to be copied to a backup volume where it can be kept as long 
as needed. For example, you could rename the current copy of ERRLOG.SYS 
to ERRLOG.OLD every morning at 9:00 o'clock. To free space on the system 
disk, you could then back up the renamed version of the error log file on 
a different volume and delete the file from the system disk. Note that 
you should exercise caution to ensure that error log files are not deleted 
inadvertently. You may also want to adopt a naming convention for your 
files that incorporates in the file name a beginning or ending date for the 
data. 


10.1.3 Printing the Error Log Files 

The following steps describe how to generate an error log report for all entries 
in the error log file and how to print the report: 

1 Ensure that you have the SYSPRV privilege. You need this privilege to 
access the error log file. 

2 Set your default disk and directory to SYS$ERRORLOG. 

3 Examine the error log directory to see which error log file you wish to 
analyze. 

4 To obtain a full report of the current error log file, issue the command: 

$ ANALYZE/ERR0E_L0G/0UTPUT=ERR0RS.LIS 

5 Print a copy of the report, using the file name specified with the 
/OUTPUT qualifier: 

$ PRINT ERRORS.LIS 

Example 

$ SET PROCESS/PRIV=SYSPRV 
$ SET DEFAULT SYS$ERR0RL0G 
$ DIRECTORY 

Directory SYSlSYSROOT:[SYSERR] 

ERRLOG.OLD;2 ERRLOG.OLD;i ERRLOG.SYS;1 
Total of 3 files. 

$ ANALYZE/ERR0R_L0G/0UTPUT=ERR0RS.LIS ERRLOG.OLD 
$ PRINT ERRORS.LIS 


10.2 Using the Operator Log File 

The operator log file (SYS$MANAGER:OPERATOR.LOG) is a system 
management tool you can use to 

• Anticipate and prevent hardware and software failures 

• Monitor user requests for disk and magnetic tape operations 

The log file records system events and user requests sent to the operator 
terminal by the operator communication process (OPCOM), even when all 
operator terminals have been disabled. The following message types appear 
in the operator's log file: 

• Initialization of the operator's log file 
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• Status reports for devices attached to the system 

• Terminals enabled and disabled 

• Volume mounts and dismounts 

• User requests and operator replies 

• Changes to system parameters through the System Generation Utility 

• Security alarm messages 

• DECnet-VAX status messages 

By regularly examining the operator log file, you can often detect tendencies 
toward problems and can thereby ensure that preventive action is taken. 

Example 10-1 illustrates some typical messages found in the operator log file. 


10-4 





Errors and Other System Events 


Example 10-1 Sample Operator Log File 

(SYS$MANAGER:OPERATOR.LOG) 


XXXXXXXXXXX OPCOM. 15-APR-1986 22:33:54.07 XXXXXXXXXXX 

Operator '_node-name$terminal-name:' has been disabled, user JONES 
XXXXXXXXXXX OPCOM, 15-APR-1986 22:34:15.47 XXXXXXXXXXX 

Operator '_node-name$terminal-name:' has been enabled, user SMITH 

xxxxxxxxxxx opcom, ib-apr-iqso 22:34:15.57 xxxxxxxxxxx 

operator status for '_node-name$terminal-name:' 

PRINTER, TAPES. DISKS. DEVICES 

y.y.mmm opcom, is-apr-iqsb 22:38:53.21 xxxxxxxxxxx 

request 1, from user PUBLIC 

Please mount volume KLATU in device MTAO: 

Gort, the tape is in cabinet A 

XXXXXXXXXXX OPCOM. 15-APR-1986 22:39:54.37 XXXXXXXXXXX 

request 1 was satisfied. 

xxxxxxxxxxx opcom, is-apr-1986 22:40:23.54 xxxxxxxxxxx 

message from user SYSTEM 

Volume "KLATU " mounted, on physical device MTAO: 

XXXXXXiXXXXX OPCOM, 15-APR-1986 22:40:38.02 XXXXXXXXXXX 

request 2, from user PUBLIC 

MOUNT new relative volume 2 () on MTAO: 

xxxxxxxxxxx opcom, ib-apr-1986 22:41:07.54 xxxxxxxxxxx 

message from user SYSTEM 

Volume "KLATU " dismounted, on physical device MTAO: 

15-APR-1986 22:42:14.81, request 2 completed by operator OPAO 
XXXXXXXXXXX OPCOM, 15-APR-1986 22:42:15.83 XXXXXXXXXXX 

request 3, from user PUBLIC 
MOUNT new relative volume 3 () on MTAO: 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:42:44.54 XXXXXXXXXXX 

message from user SYSTEM 

Volume "BERADA " mounted, on physical device MTAO: 

xxxxxxxxxxx opcom, ib-apr-1986 22:42:44.73 

message from user SYSTEM 

Volume "BERADA " dismounted, on physical device MTAO: 

I'm sorry, but we are out of tapes. 

\\XXXXXXXXXX OPCOM. 15-APR-1986 22:45:11.45 XXXXXXXXXXX 

request 3 aborted by operator OPAO 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:45:40.54 XXXXXXXXXXX 

message from user SYSTEM 

Volume "BERADA " dismounted, on physical device MTAO: 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:46:47.96 XXXXXXXXXXX 

request 4, from user PUBLIC 

_TTB5:, This is a sample user request w/ reply expected. 
XXXXXXXXXXX OPCOM. 15-APR-1986 22:47:38.50 XXXXXXXXXXX 

request 4 was canceled 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:48:21.15 XXXXXXXXXXX 

message from user PUBLIC 

_TTB5:, This is a sample user request w/o a reply expected. 
XXXXXXXXXXX OPCOM. 15-APR-1986 22:49:07.90 XXXXXXXXXXX 


Device DMAO: is offline. 

Mount verification in progress. 

XXXXXXXXXXX OPCOM. 15-APR-1986 22:49:20.22 XXXXXXXXXXX 

Mount verification completed for device DMAO: 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:49:37.64 XXXXXXXXXXX 

Device DMAO: has been write locked. 

Mount verification in progress. 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:53:54.52 XXXXXXXXXXX 


Device DMA1: is offline. 

Mount verification in progress. 

XXXXXXXXXXX OPCOM, 15-APR-1986 22:54:16.56 XXXXXXXXXXX 
Mount verification aborted for device DMA1: 

XXXXXXXXXXX OPCOM, 15-APR-1986 23:33:54.07 XXXXXXXXXXX 
message from user NETACP 
DECnet shutting down 
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10.2.1 Maintaining the Operator Log File 

The operator log file normally resides on the system disk in the [SYSMGR] 
directory. Because this file is in ASCII format, you can print it. You should 
print copies regularly and retain these copies for reference. The next section 
describes how to print copies of the operator log file. 

A new version of OPERATOR.LOG is created each time the system is 
rebooted. (You can also use the DCL command REPLY/LOG to create a 
new version of the file.) The highest version is always the one in use and is 
inaccessible. 

You should devise a plan for regular maintenance of these files. One way 
is to rename the second-highest version on a daily basis. The procedure for 
renaming the operator log file is the same as that described in Section 10.1.2 
for renaming the error log file. Do not delete versions that have not been 
backed up. 


10.2.2 Printing the Operator Log File 

The following steps illustrate how you can produce a printed copy of the 
most recent version of the operator log file. 

1 Close the current log file and open a new one by entering the following 
command: 

$ REPLY/LOG 

2 Set the default to SYS$MANAGER and issue the following command to 
list all versions of the file: 

$ DIRECTORY OPERATOR.LOG 

3 Rename the second-highest version to OPERATOR.OLD: 

$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD 

The version number, -1, specifies that the second-highest version of this 
file is to be renamed. The highest version number is the current operator 
log file. 

4 Obtain a printed copy of the operator log file by issuing the following 
command: 

$ PRINT OPERATOR.OLD 

Example 

$ REPLY/LOG 

nnnmn opcom. is-apr-iqso 12 : 29 : 24.52 nxnnnn 

log!lie initialized by operator _MARS$VTA2: 
logfile is SYStMANAGER:OPERATOR.LOG 

$ SET DEFAULT SYS$MANAGER 
$ DIRECTORY OPERATOR.LOG 

Directory SYSISYSROOT:[SYSMGR] 

OPERATOR.LOG;582 OPERATOR.LOG;581 

Total of 2 files. 

$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD 
$ PRINT OPERATOR.OLD 
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10.2.3 Restarting OPCOM 

You can restart OPCOM if for some reason it is deleted or suspended. Simply 
invoke the STARTUP command procedure in the [SYSEXE] directory and 
specify one parameter, as in the following example: 

$ <BSYS$SYSTEM: STARTUP OPCOM 

Invoke the STARTUP command procedure from the system manager's 
account. 


10.3 Using the Operator Terminal to Handle User Requests 

One of the chief operator functions, communicating with users in handling 
requests, must be performed at terminals that have been defined as operator 
terminals. You can set up an operator terminal by issuing the DCL command 
REPLY/ENABLE at the desired terminal. When you enter this command, an 
OPCOM message in the following format will be displayed at the terminal 
and written to the operator's log file: 

XXXXXXXXXXX OPCOM, dd-mmm-yyyy hh:mm:ss.cc, XXXXXXXXXXX 

Operator '_nodename$terminal-name:' has been enabled, username 'USERNAME' 

This message tells you which terminal has been established as an operator 
terminal and when it was established. 

Request Message Formats 

To communicate with you, users can issue the DCL command REQUEST, 
specifying either the /REPLY or /TO qualifier. 

If the user issues a REQUEST/REPLY command, the request is displayed at 
the operator terminal in the following format: 

y.mmm OPCOM, dd-mmm-yyyy hh:mm: ss . cc XXXXXXXXXXX 

request 'request-id' from user 'USERNAME' '_terminal-name:', "message-text" 

This message tells you which user sent the request, the time it was sent, the 
request identification number, the originating terminal, and the request itself. 

If the user issues a REQUEST/TO command, the request is displayed at the 
operator terminal in a format similar to the one above, but without a request 
identification number. The message will have the following format: 

XXXXXXXXXXX OPCOM. dd-mmm-yyyy hh:mm:ss.cc XXXXXXXXXXX 
request from user 'USERNAME' '_terminal-name:', "message-text" 

When a user issues a REQUEST/REPLY command and you have disabled 
all operator terminals with the appropriate REPLY/DISABLE commands, 
OPCOM returns a message to the user indicating that no operator coverage is 
available. However, all subsequent user requests are recorded in the operator 
log file. 

To respond to user requests, issue the REPLY command with one of the 
following qualifiers: 

• /ABORT=identification-number "message-text" 

• /PENDING=identification-number "message-text" 

• /TO=identification-number "message-text" 
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The /ABORT qualifier indicates that the user request has been canceled. 
The /PENDING qualifier places the request in a waiting state until it can be 
fulfilled or aborted. The /TO qualifier indicates that the request has been 
fulfilled. 

For more information on the REPLY command, including all the command 
qualifiers, see the VAX/VMS DCL Dictionary. 


10.4 Reporting Software Problems 

To inform DIGITAL about problems with the VAX/VMS operating system or 
about errors in VAX/VMS software documents, you should use the Software 
Performance Report (SPR), which is reproduced as Figure 10-1. Directions 
for completing the SPR form accompany the form itself. 

A supply of SPR forms is included in the VAX/VMS Software Distribution 
Kit; you can obtain more forms from an SPR center. The addresses of these 
centers are listed on the backs of the forms. 

This section offers advice on how to use this service most effectively, 
by describing the information that should be provided with all SPRs. 
Depending on the problem, this information will vary in quantity and 
content. Remember that the more information you include, the easier it 
will be for DIGITAL to resolve the problem. 


10.4.1 The Problem Environment 

You should supply a complete description, usually in the form of a batch 
log or console listing, that shows exactly how the problem evolved. Merely 
supplying erroneous output or paraphrases of the session is not enough. 
You must provide a complete scenario depicting what you did. The problem 
may be caused by an interaction between various system events, software 
packages, devices, SYSGEN parameters, DCL symbols, or logical names. 
Consider including some or all of the displays these commands produce: 

$ SHOW LOGICAL/FULL/ALL 
$ SHOW SYMBOL/ALL/GLOBAL 
$ RUN SYStSYSTEM:SYSGEN 
SYSGEN> USE ACTIVE 
SYSGEN> SHOW /ALL 
SYSGEN> SHOW /SPECIAL 


10.4.2 The Problem Scope 

As much as possible, eliminate all extraneous elements from the scenario you 
provide. For example, if the execution of a very complex program causes a 
problem, strip the program to just the code involved or write a small program 
that reproduces the problem. This action may help you locate logic errors, 
and will enable DIGITAL to isolate the difficulty more quickly. 
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Figure 10-1 Software Performance Report (SPR) 
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10.4.3 Machine-Readable Files 

Supply any software needed to reproduce the problem, if possible. This may 
include source programs, image files, sample data, command procedures, 
and other items. When you submit source programs, be sure to include any 
libraries or require files that you reference. These files should all be provided 
in machine-readable format. It is best to include console or magnetic tape 
media with an SPR. 

If a system failure has occurred, then include the system dump file. Write the 
data onto a Files-11 Structure Level 2 disk or an ANSI magnetic tape. The 
following commands will copy the system dump file to an ANSI magnetic 
tape: 

$ MOUNT/FOREIGN MTAO: DUMPS 

$ BACKUP SYS$SYSTEM:SYSDUMP.DMP/IGNORE=NOBACKUP MTAO:DUMP/SAVE_SET 

You can copy files to the console medium after invoking SYSGEN and issuing 
the following command: 

SYSGEN> CONNECT CONSOLE 

Now remove the console medium and place a scratch medium in the console 
device. 

$ INITIALIZE CSA1: SPRDATA 
$ MOUNT CSA1: SPRDATA 
$ CREATE/DIRECTORY CSA1:[SPR] 

$ BACKUP MYDATA.DAT,MYIMAGE.EXE/IGNORE=NOBACKUP CSA1:[SPR] DATA/SAVE.SET 
$ DISMOUNT CSA1: 

When you provide machine-readable data, always include the exact 
instructions used to write the medium and instructions for reading the 
medium. (Avoid using other media formats, since doing so can cause 
unnecessary problems. For example, using FLX without /IM creates an 
unusable dump file since FLX eliminates all bytes of zero.) 

Note: All machine-readable media you submit with SPRs will be returned to 
you. 


10.4.4 System Environment 

Every site runs a different type of workload. Some problems appear only 
under certain conditions. For example, some sites give different classes of 
users different base priorities. These sites may encounter problems that other 
sites do not. Such background information can be extremely important in 
resolving the problem, especially for system hangs or system failures. 

You should describe any special software packages that are running, and 
mention any unusual hardware devices or user-written drivers on your 
system. 

Also include the various version numbers of different pieces of software. 

For example, if a problem occurs while accessing local symbols during a 
DEBUG session, specify the version numbers of DEBUG and all compilers or 
assemblers used. 

Sometimes DIGITAL forwards special patches or prereleases of patches for 
problems that are seriously affecting the system. If you are using any such 
patches, mention them in the SPR. 
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10.4.5 User Analysis (Optional) 

Optionally you can include an analysis of what you believe is causing the 
problem. Include miscellaneous information, such as "the problem could 
only be reproduced when xyz happened," or "the problem does not occur on 
Version x.y." 

DIGITAL requires different kinds of information to resolve different kinds of 
problems. Use Table 10-1 as an initial checklist to begin collecting the proper 
information to forward with your SPR. 


Table 10-1 Typical Problem-Specific Information for SPRs 

Problem Information to Collect 

Command language interpreters A listing obtained from the DCL 

commands SHOW SYMBOL/ALL 
/GLOBAL and SHOW LOGICAL/FULL 
/ALL. 

Compiler or assembler A machine-readable copy of the source 

program that caused the problem, 
including all require files and libraries that 
are referenced. (Try to limit the scope of 
the problem.) 

A description of the compiler (or 
assembler) and operating system, 
including the version of each. 

Devices A copy of the error log at the time of the 

problem. 

Executive A listing of the active values of the 

system parameters. (Invoke SYSGEN 
and specify the USE ACTIVE, SHOW 
/ALL, and SHOW/SPECIAL commands.) 

A machine-readable copy of the source 
program showing the problem. 

A copy of the error log at the time of the 
problem. 

Files A listing of all the information available 

on the file, obtained with the DCL 
command DIRECTORY/FULL; or a dump 
with the header of the file's directory, 
obtained with the DCL command DUMP 
/HEADER. 

A machine-readable copy of the file 
itself. 


Intermittent A copy of the error log at the time of the 

problem. 

Job controller A copy of the console printout and 

a machine-readable copy of the file 
SYS$SYSTEM:JOBCTL.DMP, which is 
produced when the job controller aborts. 
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Table 10-1 (Cont.) Typical Problem-Specific Information for 
SPRs 


Problem 

Information to Collect 

Librarian 

A machine-readable copy of the library 
itself. 

Machine-readable copies of all input files 
to the library. 

A listing of all the information available 
on the library file, obtained from the DCL 
command DIRECTORY/FULL. 

A listing of the library contents, obtained 
from the DCL command LIBRARY/LIST 
/FULL. 

(If the problem cannot be reproduced, 
describe the scenario and include any 
command files used.) 

Linker 

Machine-readable copies of the object 
files and libraries used in the link. 

A full map obtained by the DCL 
command LINK/MAP/FULL. 

Machine check 

A copy of the error log at the time of the 
error. 

A machine-readable copy of the system 
dump file. 

Network 

A description of the configurations of 
the systems involved in the problem, 
including the versions of the operating 
systems and DECnet-VAX, the hardware 
on both systems, and the patch level 
of the DECnet software on the non- 
VAX/VMS system, if applicable. 

System bugcheck/Failure 

A machine-readable copy of the system 
dump file. (Do not send output from the 
System Dump Analyzer, since it usually 
does not provide enough information 
to resolve the problem. If you send 
the dump file, DIGITAL can always run 
SDA to obtain as much information and 
possibly more.) 

A copy of the error log at the time of 
the error to help DIGITAL determine if 
the system problem was triggered by 
hardware errors. 
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Table 10-1 (Cont.) 

Typical Problem-Specific Information for 
SPRs 

Problem 

Information to Collect 

System hang 

A copy of the system dump file, obtained 
after you crash the system in the manner 
described in the software installation 
card for your VAX processor. 

This causes the system to bugcheck in a 
manner that is recognizable as a forced 
crash. Include the console listing and 
a description of the currently running 
workload. 

Terminals 

A list of terminal characteristics produced 
by the DCL command SHOW TERMINAL. 

A description of the type of terminal, 
the type of modem (if any), any special 
front-end equipment, and any unusual 
terminal configuration. 
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When your system is installed or upgraded, a DIGITAL-supplied command 
procedure, AUTOGEN.COM in SYS$UPDATE, automatically sets the values 
of system parameters, the sizes of the primary page, swap, and dump files, 
and the contents of the default installed image list (VMSIMAGES.DAT in 
SYS$MANAGER). AUTOGEN makes these adjustments after evaluating your 
hardware configuration and estimating typical workloads. 


In many cases, AUTOGEN optimizes your new system when it is invoked 
during routine installation or upgrade procedures. You may therefore wish to 
monitor performance for a period of time before making further adjustments. 


If (based on system performance and suggestions in the Guide to VAX/VMS 
Performance Management) you decide to modify some system parameters or 
change the size of a system file, you should perform such modifications with 
AUTOGEN rather than with SYSGEN, because AUTOGEN analyzes your 
modifications and adjusts any related parameters. Sections 11.1 through 11.5 
describe AUTOGEN functions and usage. 


There are, however, certain system modifications that you must perform using 
SYSGEN. These are described in Sections 11.6 through 11.14. 



AUTOGEN Functions 

AUTOGEN performs one or more of the following operations on an upgraded 

or newly installed system: 

• Collects two types of data: 

1 Hardware configuration characteristics. 

2 Current values of SYSGEN parameters. Four sets of values (listed in 
Tables 11-5 through 11-8 at the end of this chapter) are collected in 
the files OLDSITEl.DAT through OLDSITE4.DAT in SYS$SYSTEM 
and conditionally written to SYS$SYSTEM:PARAMS.DAT. (For 
detailed descriptions of SYSGEN parameters, refer to the VAX/VMS 
System Generation Utility Reference Manual.) 

• Calculates appropriate new values for significant SYSGEN parameters 
(listed in Table 11-9) and sizes for the system page, swap, and dump files 

• Resets system parameter values and file sizes if necessary 

• Optionally shuts down and reboots the system 

You should carefully examine the PARAMS.DAT file that AUTOGEN creates 

at your site during routine installation or upgrade procedures to determine 

whether 

• AUTOGEN has drawn the correct conclusions about your hardware 
configuration. 

• The system parameter values shown are appropriate for your workload 
requirements. 
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If you are satisfied with the data in PARAMS.DAT, further adjustments are 
probably unnecessary. 

If, on the other hand, you need to correct configuration data or modify 
system parameters to accommodate special conditions at your site, invoke 
AUTOGEN as described in the next section and follow the procedures 
outlined in Sections 11.3 and 11.4. 


11.2 Invoking AUTOGEN 

You can invoke AUTOGEN any time after an installation or an upgrade to 
reset parameter values and system file sizes. The new values and file sizes 
take effect the next time the system is bootstrapped. 

To ensure that you have the required privileges, invoke AUTOGEN from the 
system manager's account. The format is: 

$ ©SYS$UPDATE:AUTOGEN [start-phase] [end-phase] [execution-type] 

You can enter up to three parameters to designate the AUTOGEN operation 
you desire. All parameters are optional; however, missing leading parameters 
must be replaced by null arguments (that is, ""). 

Table 11-1 lists the phase parameters and their effects, including the files 
needed as input and the files created or changed for output. Table 11-2 
summarizes execution types. 

All files except VMSIMAGES.DAT reside in the directory specified by the 
SYS$SYSTEM logical name. VMSIMAGES.DAT resides in SYS$MANAGER. 

The start phase must either precede or be identical to the end phase according 
to the sequence shown in Table 11-1 (the end phase defaults to the same 
value as the start phase). GENPARAMS is the default start phase; GENFILES 
may not be specified as the start phase. 


Table 11-1 AUTOGEN Phase Parameters 


Phase 

Input Files 

Output Files 

Function 

SAVPARAMS 

None 

OLDSITE*.DAT 

Save significant old parameters for 
propagation and update. 

GETDATA 

OLDSITEvDAT 

MODPARAMS.DAT 

PARAMS.DAT 

Collect all data that will be required 
by the GENPARAMS and GENFILES 
phases, including configuration data, old 
parameters, and site-specific items. 

GENPARAMS 

PARAMS.DAT 

SETPARAMS.DAT 

VMSIMAGES.DAT 

Generate new system parameters; create 
the installed image list. 

TESTFILES 

PARAMS.DAT 

SYSSOUTPUT 

Display the system page, swap, and dump 
file sizes calculated by AUTOGEN. (See 
Section 11.4 if you wish to specify sizes.) 

GENFILES 

PARAMS.DAT 

PAGEFILE.SYS 

SWAPFILE.SYS 

SYSDUMP.DMP 

Generate new system page, swap, and 
dump files if appropriate. Cannot be 
specified as the start phase. 


11-2 







System Generation 


Table 11-1 (Cont.) AUTOGEN Phase Parameters 


Phase 

Input Files 

Output Files 

Function 

SETPARAMS 

SETPARAMS.DAT 

VAXVMSSYS.PAR 
AUTOGEN.PAR 

Run SYSGEN to set system parameters 
specified by the SETPARAMS.DAT and to 
generate a new AUTOGEN.PAR file. 

SHUTDOWN 

None 

None 

Prepare the system to await a manual 
reboot. 

REBOOT 

None 

None 

Automatically reboot the system. 


Table 11-2 

Execution Types 

Type 

Meaning 

INITIAL 

Specifies that AUTOGEN is being executed as part of an initial 
system installation. The SAVPARAMS phase is never executed 
in this case. 

V4UPGRADE 

Specifies that AUTOGEN is being executed as part of an upgrade 
from a Version 4.n system or that interactive tuning is being 
performed. V4UPGRADE is the default execution type. 

V3UPGRADE 

Specifies that AUTOGEN is being executed as part of an upgrade 
from a Version 3.n system to a Version 4.n system. 


The commands and examples in the next sections illustrate AUTOGEN 
procedures you would use to adjust a typical Version 4.4 system after an 
upgrade. 


11.3 Collecting Data for AUTOGEN Calculations 

To collect the data AUTOGEN needs to perform its calculations, issue the 
following command: 

$ ©SYSIUPDATE:AUTOGEN SAVPARAMS GETDATA 

This command instructs AUTOGEN to 

• Create OLDSITE*.DAT files that store system parameter data from the 
current system 

• Collect system version, identification, and hardware configuration data 

• Collect user-specified data, if any, from MODPARAMS.DAT (see 
Section 11.4) 

• Write data to a PARAMS.DAT file for use in subsequent calculations or 
propagation to the new system 

Example 11-1 shows a typical PARAMS.DAT file. The first group of items 
is a list of AUTOGEN's conclusions about the system version, system ID, 
and hardware components. (Table 11-3 defines these items.) You should 
scrutinize the Boolean items to verify that AUTOGEN has drawn the correct 
conclusions about your hardware configuration. 
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The next items are system parameter values collected in OLDSITE*.DAT 
files or specified in MODPARAMS.DAT. Parameters preceded by an OLD_ 
prefix will be used within calculations. Other parameters will be written to 
SETPARAMS.DAT and propagated to the new system. 

Note: Values displayed in PARAMS.DAT as input from MODPARAMS.DAT 
override corresponding configuration values and values from 
OLDSITE*.DAT files. 
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Example 11-1 Sample AUTOGEN PARAMS.DAT File 


! This data file should NOT be modified. Users wishing to alter the 
! data in this file should modify SYS$SYSTEM:MODPARAMS.DAT instead. 

i 

VERSI0N="V4.2 
CPUTYPE=1 
SID=20455546 
QVSS="false" 

MEMSIZE=16384 

DISKSPEED=4 

DISKSIZE=340670 

NUM_DISK=77 

NUM_TAPE=5 

NUM_SC0M=10 

NUM_CARD=0 

NUM_TERM=74 

NUM_LP=4 

NUM_REALTIME=0 

NUM_BUS=2 

NUM_MAILB0X=0 

NUM_J0URNAL=0 

NUM_MISC=0 

NUM_CI=1 

NUM_ETHERNET=3 

NUM_SERVER=2 

NUM_H0ST=1 

DRIVER_NPAGEDYN=188226 

DECNET="true" 

CLUSTERS true" 

JOURNALING="false" 

PEDRIVER_LOADED="false" 

! Parameters specified in SYS$SYSTEM:0LDSITE1.DAT 

OLD_GBLPAGES=20240 

0LD_GBLSECTI0NS=2OO 

0LD_GBLPAGFIL=512O 

0LD_MAXBUF=2100 

0LD_MAXPR0CESSCNT=96 

OLD_VIRTUALPAGECNT=48000 

! Parameters specified in SYS$SYSTEM:OLDSITE2.DAT 

CLISYMTBL=80 

PQL_DWSDEFAULT=458 

PQL_DWSQU0TA=458 

PQL_MWSDEFAULT=458 

PQL_MWSQU0TA=458 

! Parameters specified in SYS$SYSTEM:0LDSITE3.DAT 

ACP_SWAPFLGS=14 

DEADL0CK_WAIT=1 

MVTIMEOUT=1200 

PAGFILCNT=5 

REALTIME_SPTS=40 

SCSSYSTEMID=2217 

SWPFILCNT=3 

TIMEPR0MPTWAIT=65535 

TTY_ALTYPAHD=2048 

USERD1=1 

! Parameters specified in SYS$SYSTEM:0LDSITE4.DAT 

ACP_REBLDSYSD=0 

DISK_QU0RUM="$255$DUA5 

QU0RUM=3 

SCSN0DE="CURLEY " 

TTY_DEFCHAR2=135178 


(Continued on next page) 
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Example 11-1 (Cont.) Sample AUTOGEN PARAMS.DAT File 


! Parameters specified in SYS$SYSTEM:MODPARAMS.DAT 
! MODPARAMS.DAT for CURLEY 

i 

! All Bite-specific SYSGEN parameters not computed correctly or 
! propagated by AUTOGEN should be defined here. 

i 

PAGEFILE = 10000 


SWAPFILE = 0 
ADD.SPTREQ * 400 
GBLPAGES = 20240 
NUM.HOST * 6 
NUM.SERVER = 8 

! for MA780 

! 10240 + 10000 for MA780 


end of MODPARAMS.DAT for CURLEY 

This data file should NOT be modified. Users wishing to alter the 
data in this file should modify SYS$SYSTEM:MODPARAMS.DAT instead. 


Table 11-3 Configuration Parameters Specified in 
Example 11-1 


Parameter 

Specifies 

VERSION 

Version number of VAX/VMS used to create this file 

CPUTYPE 

Code for the VAX processor model number as specified 
by the $GETSYI system service 

SID 

System identification number 

MEMSIZE 

Physical memory size, in pages 

DISKSPEED 

Code for speed of system disk; values are 1, 2, or 4, 
where 4 is the fastest category of disks 

DISKSIZE 

System disk size in blocks 

NUM_DISK 

Total number of disk devices 

NUM_TAPE 

Total number of magnetic tape devices 

NUM_SCOM 

Total number of system communication devices 

NUM_CARD 

Total number of card readers 

NUM_TERM 

Total number of terminal lines available 

NUM_LP 

Total number of printers 

NUM_REALTIME 

Total number of real-time devices 

NUM_BUS 

Total number of buses 

NUM_MAILBOX 

Total number of mailboxes 

NUM_MISC 

Total number of miscellaneous devices 

NUM_JOURNAL 

Reserved for future use 

NUM_CI 

Total number of computer interconnects 

NUM_ETHERNET 

Number of Ethernet connections 

NUM_SERVER 

Number of disk or tape servers that use the MSCP 
protocol (HSC50, UDA50, VAX systems running the 
MSCP server software) 
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Table 11-3 (Cont.) 

Configuration Parameters Specified in 
Example 11-1 

Parameter 

Specifies 

NUM_HOST 

Number of VAX/VMS systems that are members of a 
VAXcluster 

DRIVER_NPAGEDYN 

Bytes of nonpaged pool taken up by drivers 

DECNET 

Whether DECnet is installed 

CLUSTER 

Whether node is member of a VAXcluster 

JOURNALING 

Reserved for future use 

PEDRIVER_LOADED 

Whether PEDRIVER is loaded 

WSTYPE 

Whether VAXstation is present on the system 


11.4 Modifying AUTOGEN Calculations 

If, after examining the PARAMS.DAT file, you decide you wish to correct 
hardware configuration data, modify system parameter values, or explicitly 
specify sizes for the system page, swap, or dump files (that is, override the 
sizes calculated by AUTOGEN), follow the steps outlined in this section. 

Depending on the adjustments you are making, you may want to invoke 
AUTOGEN several times, specifying different parameters. 

1 Edit the file SYS$SYSTEM:MODPARAMS.DAT as follows: 

• To specify new parameter values, use DCL assignment statements of 
the form: 

parameter = parameter-value ! comment 

Using the exact parameter name will override the AUTOGEN 
calculation. You can also use an ADD_ prefix with the SYSGEN 
parameters listed in Table 11-9 to increment their values in subsequent 
AUTOGEN calculations during the GENPARAMS phase. For example: 

ADD_MAXPROCESSCNT=10 
ADD_NPAGEDYN=10000 

The ADD_ parameter value can be negative in order to lower 
AUTOGEN's calculated value by the specified amount (for example 
- 10 ). 

• To specify system file sizes explicitly, use the keywords PAGEFILE, 
SWAPFILE, and DUMPFILE followed by an equal sign and the size 
of the file in blocks. The values you specify (which are set during the 
GENFILES phase) will override AUTOGEN's calculations until you 
remove the lines from MODPARAMS.DAT. 

Note: AUTOGEN will not change file sizes if you specify a value of 0, or 
a value that is within ten percent of the current size. 

To determine the current sizes of page and swap files, issue the DCL 
command SHOW MEMORY/FILE. 

The parameter values and file sizes specified in MODPARAMS.DAT will 
be copied into PARAMS.DAT during the next GETDATA phase, and 
AUTOGEN will make appropriate adjustments in its calculations. 
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2 Verify the modifications you have made in MODPARAMS.DAT. Issue the 
command 

$ OSYS$UPDATE:AUTOGEN GETDATA 

and examine the resulting PARAMS.DAT file (see Example 11-1). 

If you wish to make further modifications to the data in PARAMS.DAT, 
edit MODPARAMS.DAT and repeat the GETDATA phase. 

Caution: Under no circumstances should you attempt to edit PARAMS.DAT. All 
modifications to this file must be made by editing MODPARAMS.DAT 
and executing AUTOGEN's GETDATA phase. 

3 When you are satisfied with the data in PARAMS.DAT, issue the following 
command: 

$ <8SYS$UPDATE: AUTOGEN GENPARAMS SETPARAMS 

AUTOGEN will generate the known image file list, VMSIMAGES.DAT, 
and it will create SETPARAMS.DAT, using in its calculations the 
parameter values you specified in MODPARAMS.DAT. It will 
then run SYSGEN to set values for your upgraded system in 
SYS$SYSTEM:VAXVMSSYS.PAR. The new values are also propagated 
to SYS$SYSTEM:AUTOGEN.PAR. 

4 Finally, when you are ready to reboot the system, issue the command 

$ <BSYS$UPDATE: AUTOGEN REBOOT 

Note that you can define the logical name AGEN$SHUTDOWN_TIME 
(using the DCL command DEFINE) to specify the number of minutes 
before shutdown occurs in this operation. 

Once you complete the AUTOGEN REBOOT operation, you can verify the 
parameter changes. Invoke SYSGEN and display the parameters with the 
SYSGEN command SHOW/ALL. 


11.5 Manipulating System Files 

As described in the previous section, you can use AUTOGEN to adjust the 
sizes of the primary page and swap files, and the system dump file. However, 
you cannot use AUTOGEN to perform any operations on secondary page 
and swap files. To create, install, or modify secondary files, you must use 
SYSGEN (see the VAX/VMS System Generation Utility Reference Manual ). 

Note: If you have created secondary page or swap files, specify a value of 0 
for the keywords PAGEFILE and SWAPFILE in MODPARAMS.DAT. 
This instructs AUTOGEN not to create new primary files. AUTOGEN 
will issue a warning message if it determines that secondary files exist 
and a value of 0 has not been specified for the above keywords. See the 
Guide to VAX /VMS Performance Management for more information on 
secondary system files. 

By following the procedures in the previous section, you can use AUTOGEN 
to create a page, swap, or dump file that is smaller than the current version 
of the file. After you have booted and begun using the new file, remember to 
use the DCL command PURGE to reclaim the disk space from the old version 
of the file. 
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11.6 SYSGEN Functions 

Using SYSGEN, you can manipulate the following parts of the VAX/VMS 

operating system: 

• System parameters—Create and/or modify a standard system parameter 
file for use in subsequent bootstrap operations; dynamically modify the 
parameter values of the active system (applies only to the dynamic system 
parameters) 

• Devices and device drivers—Connect devices and load their device drivers 
(most of this work is automatic) 

• System files—Create additional page and swap files 

• Startup command procedure—Identify the current site-independent startup 
command procedure 

• Multiport (shared) memory—Initialize and connect to multiport memory 
units 

• MSCP server—Load and start the MSCP server (see the Guide to 
VAXclusters). 

See the VAX/VMS System Generation Utility Reference Manual for full details 

of the System Generation Utility and its commands. 


11.7 Modifying System Parameters 

The bootstrap process initializes the active system parameter values in 
memory from the current system parameter file on disk (that is, the 
starting parameter values are those in SYS$SYSTEM:VAXVMSSYS.PAR). 

In a conversational bootstrap operation, you can modify these values by 
reinitializing the active parameter values from a parameter file or the default 
list, and by setting new parameter values on an individual basis. At the end 
of the bootstrap operation, the system parameter file is modified to conform 
to the active parameter values. 

Warning: Many of the system generation parameters can affect other parameters or 
the performance of the system. It is suggested that you make changes to 
system parameters by editing the file SYS$SYSTEM:MODPARAMS.DAT 
and reinvoking AUTOGEN. 

After the system is booted and running, you can run SYSGEN to create or 
modify parameter files, including the current system parameter file, and to 
modify the dynamic parameter values of the active system. Follow these 
steps: 

1 Invoke SYSGEN—Invoking SYSGEN initializes a work area for the active 
parameter values. 

2 Optionally issue a USE command—You can reinitialize the work area to 
include the values of a new parameter file, the current system parameter 
file, or the default values, if the active values do not provide a suitable 
base for subsequent operations. 

3 Issue SET commands—You modify parameters on an individual basis. 
These modifications have no effect outside the SYSGEN work area. 
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4 Issue a WRITE command—You create a parameter file, modify the current 
system parameter file on disk, or modify the active system in memory. 

During these operations, you can use the SHOW command to examine the 
parameter values in the SYSGEN work area. 


11.7.1 Creating a New Parameter File 

The creation of a new parameter file does not affect the system. During a 
subsequent conversational bootstrap operation, however, you can initialize 
the active system with the values of the new file. The following example 
creates a new version of the AUTOGEN.PAR system parameter file with a 
new value for the REALTIME _SPTS parameter: 

$ SET DEFAULT SYS$SYSTEM 
$ RUN SYSGEN 
SYSGEN> USE AUTOGEN 
SYSGEN> SET REALTIME.SPTS 10 
SYSGEN> WRITE AUTOGEN 
SYSGEN> EXIT 

The next example creates a user file named SYS$SYSTEM:OURSITE.PAR, 
using the AUTOGEN.PAR file as a base: 

$ SET DEFAULT SYS$SYSTEM 
$ RUN SYSGEN 
SYSGEN> USE AUTOGEN 
SYSGEN> SET REALTIME_SPTS 10 
SYSGEN> WRITE OURSITE 
SYSGEN> EXIT 


11.7.2 Modifying the System Parameter File 

Modification of the current system parameter file also does not immediately 
affect the system. During subsequent bootstrap operations, however, the 
active system is initialized with the new values. A conversational bootstrap 
operation permits you to modify these values further, while a nonstop 
bootstrap operation makes the new values the values of the active system. 
The following example modifies the REALTIME _SPTS parameter value in 
the system parameter file: 

$ SET DEFAULT SYS$SYSTEM 
$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> USE CURRENT 
SYSGEN> SET REALTIME.SPTS 10 
SYSGEN> WRITE CURRENT 

'/.0PC0M, 15-APR-1986 16:04:06.30, message from user SYSTEM 
'/.SYSGEN-1-WRITECUR, CURRENT system parameters modified by process 
ID 00160030 
SYSGEN> EXIT 
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11.7.3 Modifying the Active System 

Modification of the active system immediately affects that subset of the 
system parameters called the dynamic parameters by changing their values in 
memory. The discussion of the System Generation Utility in the VAX/VMS 
System Generation Utility Reference Manual identifies the dynamic parameters 
(as does the SYSGEN command SHOW/DYNAMIC). The other parameters 
regulate structures that cannot be changed while the system is running. 

The following example illustrates how you modify the active value of the 
PFCDEFAULT parameter: 

$ RUN SYSSSYSTEM:SYSGEN 
SYSGEN> SET PFCDEFAULT 127 
SYSGEN> WRITE ACTIVE 

•/.OPCOM, 15-APR-1986 16:04:06.30, message from user SYSTEM 
’/.SYSGEN-1-WRITEACT, ACTIVE system parameters modified by process 
ID 00160030 
SYSGEN> EXIT 

Modification of the active system does not affect the current system parameter 
file on disk. If, for example, you set new active parameter values (WRITE 
ACTIVE) and later want to use them for subsequent bootstrap operations, the 
values must be explicitly written to the current system parameter file on disk: 


$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> WRITE CURRENT 

*/,0PC0M, 15-APR-1986 16:04:06.30, message from user SYSTEM 
•/.SYSGEN-1-WRITECUR, CURRENT system parameters modified by process 
ID 00160030 into file VAXVMSSYS.PAR 
SYSGEN> EXIT 


11.8 Connecting Devices and Loading Device Drivers 

Normally, you issue the AUTOCONFIGURE command to connect 
automatically all devices physically attached to the system and to load their 
device drivers, saving a great deal of effort and reducing the possibility of 
error. Devices not attached to the system and devices with nonstandard 
names can be connected and their device drivers loaded with explicit 
CONNECT (or CONNECT and LOAD) commands. You must exercise 
great care in issuing CONNECT and LOAD commands. (See the discussion 
of the System Generation Utility in the VAX/VMS System Generation Utility 
Reference Manual and the Writing a Device Driver for VAX/VMS.) 

Devices not connected automatically by AUTOCONFIGURE include the 
network communications logical device and the console block storage device. 
To connect the network communications logical device, use the following 
explicit CONNECT command: 

SYSGEN> CONNECT NET/NOADAPTER/DRIVER=NETDRIVER 

To connect the console block storage device, use the following explicit 
CONNECT command: 

SYSGEN> CONNECT CONSOLE 

The commands in the following example autoconfigure the devices physically 
attached to the system and explicitly connect the network software device and 
the console block storage device: 

SYSGEN> AUTOCONFIGURE ALL 

SYSGEN> CONNECT NET/NOADAPTER/DRIVER=NETDRIVER 
SYSGEN> CONNECT CONSOLE 
SYSGEN> EXIT 
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Normally, the SYSGEN commands for connecting devices and loading device 
drivers are included in the site-independent startup command procedure (see 
Section 2). 

Note that there is a DIGITAL-supplied driver named CONINTERR 
(SYS$SYSTEM:CONINTERR.EXE), which permits real-time processes to 
connect to interrupt vectors for quick response to and special handling of 
real-time events. The driver is not associated with any one device type. See 
the VAX/VMS I/O User's Reference Manual: Part I for further information. 


11.9 Using the SET HOST/HSC Facility 

The SET HOST/HSC facility allows system managers to use most HSC 
commands and utilities from a remote terminal. This facility is useful for 
performing management operations such as obtaining the status of disks and 
tapes, and running the HSC backup and restore utilities. 

To activate the facility, you must first install and load FYDRIVER, 
the diagnostic and utilities protocol (DUP) driver associated with 
the computer interconnect (Cl). The preferred method is to add 
the following command lines to your site-specific startup procedure 
(SYS$MANAGER:SYSTARTUP.COM): 

$ RUN SYS$SYSTEM:SYSGEN 
CONNECT FYAO/NOADAPTER 

After SYSTARTUP.COM executes, you can use the DCL command 

SET HOST/HSC to connect to an HSC by way of the Cl bus. For a complete 

description of this command, refer to the VAX/VMS DCL Dictionary. 

Once connection is made, you are attached to the local HSC terminal, and 
you may perform operations (with the exception of access to the Octal 
Debugging Tool (ODT) and offline diagnostics). For a description of HSC 
commands and utilities, see the HSC User's Guide . 


11.10 Setting Up Virtual Terminals 

Virtual terminals allow you to disconnect from a physical terminal 
without terminating a process; the process remains active on a virtual 
or "disconnectable" terminal. Virtual terminals are used for the following 
purposes: 

• To reconnect to a process when a modem line connection is lost 

• To maintain sessions on more than one disconnectable terminal. 

• To use dynamic asynchronous DECnet communication 

You set up virtual terminals by issuing the following SYSGEN command, 
which allows physical terminals to become disconnectable: 

SYSGEN> CONNECT VTAO/N0ADDAPTER/DRIVER=TTDRIVER 

Virtual terminals are identified by the device name VTAn. After the above 
SYSGEN command is issued, any terminal with the TT2$M_DISCONNECT 
characteristic set is treated as a virtual terminal. 

Note: LAT terminals (LTAn) are disconnectable if the TT2$M_DISCONNECT 
characteristic is set, but remote terminals (RTAn) are not disconnectable. 
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There are two ways to set the TT2$M_DISCONNECT characteristic. You 
can enable the feature on a systemwide basis by setting the appropriate bit in 
the SYSGEN parameter TTY_DEFCHAR2, or you can enable the feature on a 
per-terminal basis by using the DCL command SET 

TERMINAL/DISCONNECT. Consult the VAX/VMS DCL Dictionary for more 
information on the CONNECT and DISCONNECT commands. 


11.10.1 Reconnecting to a Disconnected Terminal Process 

If virtual terminals are enabled, and a modem line connection is lost, the 
process remains active on the system as a disconnected virtual terminal 
process. You must reconnect to the process within the time period specified 
by the SYSGEN parameter TTY_TIMEOUT (the default value is 900 seconds 
or 15 minutes). If you fail to reconnect to the process before this time expires, 
the process is deleted. 

Note: You can connect only to virtual terminal processes associated with your 
user identification code (UIC). 

There are four ways in which a terminal can become disconnected: 

• You lose the modem signal between the host and the terminal. 

• You press the BREAK key on a terminal with the TT2$M_SECURE 
characteristic set. 

• You issue the DCL command DISCONNECT. 

• You issue the DCL command CONNECT/CONTINUE. 

To reconnect to a disconnected terminal, use one of the following methods: 

• Allow the system login process (SYS$LOGIN) to make the connection 
using a command procedure. 

• Issue the DCL command, CONNECT VTAn. 


11.10.2 Managing Disconnected Processes 

Virtual terminals allow you to maintain more than one disconnected process 
at a time. You must keep in mind, however, that while you are logged 
in to a virtual terminal the physical terminal is disconnected. Any I/O 
requests directed to a device other than the physical terminal associated 
with your current virtual terminal process will enter a waiting state. The 
pending process will terminate when the timeout period expires. If, however, 
you reconnect to the physical terminal that is to receive the I/O request, 
the process continues from the point at which it entered the waiting state. 
Naming each process with a name that relates to its context makes it easier to 
reconnect to the desired process. 

A system manager may want to restrict the use of virtual terminals. For 
example, if your system is close to exhausting nonpaged pool, you may not 
want to enable this feature on a systemwide basis. Each virtual terminal 
requires an additional data structure, a logical unit control block (UCB), in 
addition to the data structure for each physical terminal. You can control the 
number of virtual terminal sessions by the value specified in the SYSGEN 
parameter MAXDETACH, or restrict the use of virtual terminals by enabling 
them on a per-terminal basis. 
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11.10.3 Using Dynamic Asynchronous DECnet Lines 

Virtual terminals are required for dynamic asynchronous DECnet 
communication. A dynamic asynchronous line differs from a static 
asynchronous line or other DECnet-VAX line in that it is normally switched 
on for network use only for the duration of a dialup connection between two 
nodes. Dynamic switching of terminal lines to asynchronous DDCMP lines 
can occur provided the following requirements are met: 

• Both nodes have DECnet-VAX licenses installed. 

• The system manager at each node has loaded the asynchronous DDCMP 
driver NODRIVER. 

• The system manager at each node has installed the privileged shareable 
image DYNSWITCH. 

• The system manager at the remote node has virtual terminals enabled. 

See the VAX/VMS Networking Manual for a detailed description of the 
procedure for setting up dynamic asynchronous DECnet lines. 


11.10.4 Determining the Physical Terminal Type 

You may want to determine the physical terminal associated with a virtual 
terminal. For instance, both direct connect and LAT lines may be virtual, but 
you may not know the terminal characteristics of a LAT terminal at system 
startup time. You can set the characteristics of direct connect lines at system 
startup; however, you must issue a SET TERMINAL/INQUIRE command to 
determine the characteristics of a LAT line. 

Note: Using the command SET TERMINAL/INQUIRE clears the type-ahead 
buffer. 

The following command procedure determines the physical terminal 
characteristics of both direct and LAT lines at system startup. Insert the 
following lines in your systemwide login procedure (SYLOGIN.COM). (This 
procedure assumes that your startup procedure has set all switched and LAT 
lines to "unknown".) 

$ DEVCLASS = 'F$GETDVI ("SYS$COMMAND","DEVCLASS")' 

$ IF DEVCLASS .ne. 66 then goto alldone !Not a terminal 
$ DEVTYPE = 1 F$GETDVI ("SYS$COMMAND","DEVTYPE")' 

$ IF DEVTYPE .ne. 0 then goto got_devtype 
$ SET TERMINAL/INQUIRE !Try to determine the device type 
$ DEVTYPE = 'F$GETDVI ("SYS$COMMAND","DEVTYPE")' 

$ got.devtype: 

$! Can now dispatch on 'devtype' to do different things depending 
$! on the type of terminal. 

$ alldone: 
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11.11 Modifying System Files 

When your system is installed or upgraded, AUTOGEN defines sizes for the 
primary page and swap files appropriate for your hardware configuration, 
and for the system dump file. The full file specification of each file is 
SYS$SYSTEM:filename.type. The file names are PAGEFILE.SYS for the 
page file, SWAPFILE.SYS for the swap file, and SYSDUMP.DMP for the 
dump file. Sizes are expressed in blocks. 

AUTOGEN creates system files suitable for most systems. For special 
workloads or variant configurations, however, you must specify the 
file sizes with the SYSGEN command CREATE. (Or—to create primary 
files only—you can invoke a DIGITAL command procedure called 
SYS$UPDATE:SWAPFILES.COM and enter file sizes when the procedure 
prompts you for them.) The following example illustrates the use of the 
CREATE command (assume that smaller versions of each file already exist): 

SYSGEN> CREATE PAGEFILE.SYS /SIZE=16384 

‘/.SYSGEN-I-EXTENDED. SYS$SYSROOT: [SYSEXE] PAGEFILE. SYS ; 1 extended 
SYSGEN> CREATE SWAPFILE.SYS /SIZE=7168 

'/.SYSGEN-1-EXTENDED, SYS$SYSROOT: [SYSEXE] SWAPFILE. SYS; 1 extended 
SYSGEN> CREATE SYSDUMP.DMP /SIZE=2052 

'/S Y SGEN -1 - EXTENDED, SYS$SYSR00T: [SYSEXE] SYSDUMP. DMP; 1 extended 
SYSGEN> EXIT 

The next example uses the command procedure: 

$ ®SYS$UPDATE:SWAPFILES 

To leave a file size at its current value type a 
carriage return in response to its size prompt. 

Current file sizes are: 

Directory SYS$SYSR00T:[SYSEXE] 

PAGEFILE.SYS;1 16384 

SYSDUMP.DMP;1 4128 

SWAPFILE.SYS;1 3072 

Total of 3 files, 23584 blocks. 

There are 128741 available blocks on SYS$SYSDEVICE. 

Enter new size for page file: jRET 1 
Enter new size for system dump file: 6052 
Enter new size for swap file: |RET| 

'/.SYSGEN-1-EXTENDED, SYS$SYSR00T: [SYSEXE] SYSDUMP . DMP; 1 extended 
*********************************************************************** 

* Please reboot in order for the new files to be used by the system. * 

* After rebooting, purge obsolete copies of the files. * 

* DO NOT delete the old files until after the reboot. * 

*********************************************************************** 

Both the command procedure and the CREATE command automatically 
extend the size of a page or dump file if you specify a size that is larger than 
that of an existing file. (However, if you have explicitly installed a file with 
the SYSGEN command INSTALL, the file cannot be extended; instead, a 
new version of the file is created.) If you specify a smaller size for a system 
page or dump file, a new version of the file is created. If the swap file does 
not exist, you can create it using the SYSGEN command CREATE, or by 
responding to the appropriate prompt from the SWAPFILES procedure. 

Frequent file creation and deletion can cause the free space on a disk to 
become severely fragmented. Eventually, this can reach a state such that 
extensions to a file require more than one header block to map all the extents 
of the file. The bootstrap process requires that SWAPFILE.SYS (the primary 
swap file, if present) and PAGEFILE.SYS (the primary page file) be mapped 
by a single file header. 
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Note: SYSGEN issues a warning message if it determines that the creation or 
extension of a system file would cause that file to become fragmented 
enough to render the system unbootable. If this occurs, DIGITAL 
recommends that you back up and restore your system volume, in order 
to consolidate the free space on the volume into one contiguous area, 
and then retry the SYSGEN operation. In cases where SYSGEN issues a 
warning message, the file will be somewhat larger, but not as large as the 
value specified in the CREATE command. 

If you create a new version of a system file, you must delete the old version 
explicitly (but not until after the next bootstrap operation). In the case of a 
primary file (PAGEFILE.SYS, SWAPFILE.SYS, or SYSDUMP.DMP), the new 
or extended size file does not become effective until the system is shut down 
and restarted. In the case of a secondary file, the new file becomes effective 
when it is installed. 

You can calculate appropriate sizes for your system files as follows: 

• Page file—Size of the average program at your site (in pages) times the 
maximum number of processes (MAXPROCESSCNT system parameter). 
The system installation sets an initial size for your primary page file. You 
can display statistics on your page file usage with the DCL command 
SHOW MEMORY/FILE. Examine the data pertaining to the page files. 
Aim to keep page file usage less than half the size of the page files. 

You can limit the usage of page file space by user programs with 

the /PGFLQUOTA qualifier of the ADD and MODIFY commands in 
the Authorize Utility (see the VAX/VMS Authorize Utility Reference 
Manual). You should not reduce the value of /PGFLQUOTA below 
1024. Size requirements of the page file can vary widely depending on 
user applications. Sufficient space in the page file is critical to system 
performance. If a page file starts to fill to the point where system 
performance is being affected, a message will be printed on the console 
terminal. Should this happen, you should increase the size of your page 
file. 

• Dump file—Size of physical memory in pages (to save the contents of 
memory if the system fails) plus four pages (to provide continuity of the 
error log when the system is shut down or if the system fails). 

• Swap file—Maximum number of processes (MAXPROCESSCNT system 
parameter) times the average of the working set quotas of processes 
running on the system. The system installation sets an initial size for 
SWAPFILE.SYS based on your hardware configuration. As an alternative 
to trying to calculate a more accurate swap file size, you can monitor the 
swap file usage with the DCL command SHOW MEMORY/FILE and 
watch its usage under load. You should aim to keep at least one-fourth of 
the swap file space unused; otherwise system performance can be severely 
affected. 

At bootstrap time, the system activates the latest versions of 
SYS$SYSTEM:PAGEFILE.SYS, SWAPFILE.SYS, and SYSDUMP.DMP. After 
bootstrapping, you can augment the primary page or swap file with additional 
files (created with the SYSGEN command CREATE) by issuing the SYSGEN 
command INSTALL. 

The advantages to using secondary files are that they do not have to be on 
the system disk and that they can span volumes in a volume set. Where 
secondary files are used, you should include SYSGEN INSTALL commands 
for the secondary files in the site-specific startup command procedure (see 
Section 2). If you are using secondary files because there is a shortage of 
disk space on the system disk, you can reduce the size of PAGEFILE.SYS to 
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a value as low as 4600 blocks, or SWAPFILE.SYS to a value as low as 1000 
blocks. 

All processes created after installation of additional page files use the page 
file with the most space, while all processes created before their installation 
continue to use the page file to which they are assigned. Swap space is 
allocated from whichever swap file has space. 

Installation of additional page or swap files requires nonpaged dynamic 
memory for a bit map, just as the primary files do. 


11.12 Identifying a Startup Command Procedure for Bootstrap Operations 

Section 2 describes the site-independent startup command procedure named 
SYS$SYSTEM:STARTUP.COM, which DIGITAL supplies and recommends 
that you do not edit. Following a bootstrap operation, the system executes 
the current site-independent startup command procedure. Initially (that is, as 
supplied in the software distribution kit), the procedure is STARTUP.COM. 

However, if necessary, you can create alternate site-independent startup 
command procedures; for example, you can copy STARTUP.COM to other 
files of type COM and edit those files. You can then name an alternate site- 
independent command procedure to be invoked during subsequent bootstrap 
operations, using the SYSGEN command SET/STARTUP. You can use the 
SHOW/STARTUP command to display the current site-independent startup 
command procedure. 

The SYSGEN commands in the following example display the current site- 
independent startup command procedure and specify an alternate: 

SYSGEN> SHOW/STARTUP 

Startup command file = SYS$SYSTEM:STARTUP.COM 
SYSGEN> SET/STARTUP SYS$SYSTEM:XSTARTUP.COM 
SYSGEN> WRITE CURRENT 

'/.0PC0M, 15-APR-1986 16:04:06.30, message from user SYSTEM 
'/.SYSGEN-1-WRITECUR, CURRENT system parameters modified by process 
ID 00160030 into file VAXVMSSYS.PAR 
SYSGEN> EXIT 


11.13 Initializing Multiport (Shared) Memory Units 

A single processor can attach one or two multiport memory units, each 
of which may vary in size from 256KB to 2MB. The front panel of each 
multiport memory unit displays the number of that unit. When you issue the 
SYSGEN command SHARE/INITIALIZE SYSGEN polls the processors with 
ports on the specified multiport memory unit. If no other processors are using 
the unit, the unit is initialized. If another processor is using the unit, the unit 
is connected. A SHARE command without the /INITIALIZE qualifier, for an 
uninitialized multiport memory unit, results in an error condition. 

You should power down a multiport memory unit only after first shutting 
down and rebooting all systems connected to the unit. 

A multiport memory unit managed by VAX/VMS contains the following 
preallocated structures, with space requirements as indicated: 

• Common data page—Description of VAX/VMS data structure and quotas 
for the shared memory 
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• Global section description (GSD) table—Total global sections, as specified 
in the SHARE command, times 100 bytes, rounded up to the next full 
page 

• Mailbox table—Total mailboxes, as specified in the SHARE command, 
times 48 bytes, rounded up to the next full page 

• CEF table—Total common event flag clusters, as specified in the SHARE 
command, times 80 bytes, rounded up to the next full page 

• PRQ pool—Total interprocess or request messages, as specified in the 
SHARE command, times 64 bytes, rounded up to the next full page 

• Dynamic pool—Number of blocks allocated to the pool, as specified in the 
SHARE command, times the size of each block, as specified in the SHARE 
command 

• Global section bit map—One page 

• Global sections—Size of multiport memory unit minus the sum of the 
above preallocated structures (that is, the remaining space) 

The following SYSGEN command SHARE specifies the default structure 
values for a 256KB multiport memory unit with four active ports. The 
resulting values are shown in Table 11-4. 

SYSGEN> SHARE MPMO SHR_MEM_1/INITIALIZE- 
SYSGEN> /GBLSECTI0NS=32/MAILB0XES=32- 
SYSGEN> /CEFCLUSTERS=32/P00LBC0UNT ss 128- 
SYSGEN> /P00LBSIZE=128/PRQC0UNT=64 


Table 11-4 Values for Multiport Memory Structures 


Structure 

Value 


CEF TABLE 

32 x 80 

= 5 pages 

COMMON DATA PAGE 

1 

= 1 page 

DYNAMIC POOL 

128 x 128 

= 32 pages 

GLOBAL SECTIONS 

512 - 57 

= 455 pages 

GLOBAL SECTION BIT MAP 


= 1 page 

GSD TABLE 

32 x 100 

= 7 pages 

MAILBOX TABLE 

32 x 48 

= 3 pages 

PRQ POOL 

64 x 64 

= 8 pages 


The following guidelines are suggested in selecting values for the SHARE 
qualifiers that regulate the sizes of the preallocated structures: 

• /CEFCLUSTERS, /GBLSECTIONS, and /MAILBOXES—You should 
simply specify the maximum number of each type of structure required by 
all processors at any one time. The same structure being used by many 
processes on one or more processors counts as just one structure. 

• /POOLBCOUNT and /POOLBSIZE—The primary use of the dynamic 
pool is to buffer mailbox messages. The size of a message is 28 bytes plus 
the data in the message. Since space from the pool is always allocated 

in whole blocks, the recommended block size is the median message 
size plus 28. A block size that is too small for a message requires extra 
system overhead to concatenate the message blocks into the user buffer 
and segment them out of the user buffer. The number of blocks should 
be sufficient to satisfy all messages that might be outstanding at once. 
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If a mailbox request cannot be satisfied due to insufficient pool space, 
the requesting process enters a resource wait state or the request fails (if 
resource wait mode is not enabled), just as if the nonpaged dynamic pool 
were depleted. For this reason, you should tend to overestimate space 
requirements in the dynamic pool. 

• /PRQCOUNT—The system uses interprocessor request blocks internally 
to transfer requests among the VAX/VMS executive routines and mailbox 
drivers on the different processors. PRQs are allocated and deallocated 
rapidly, so a large number should not be needed. The default value 
normally suffices. If an executive or driver request cannot be satisfied 
because PRQs are depleted, the requesting routine waits until a PRQ 
becomes available. 

You should calculate the space remaining for the global sections and 
determine whether it is sufficient. If the space is insufficient, you might 
reduce the size of the dynamic pool. However, this condition really suggests 
the need for a larger or additional multiport memory unit. 

Where a multiport memory unit is a normal part of the system configuration, 
you should include the SYSGEN commands to initialize and connect it in the 
site-specific startup command procedure (see Section 2). 


11.14 Loading and Starting the MSCP Server 

The Mass Storage Control Protocol (MSCP) is used to communicate between 
a VAX host and a DIGITAL Storage Architecture (DSA) controller. The 
MSCP server enables a VAX processor to make locally connected MASSBUS 
and UNIBUS disks available to all other users of a VAXcluster. (As system 
manager, however, you must decide which disks should be that widely 
available.) 

You use the SYSGEN command MSCP to load and start the MSCP server. 
You then specify the served devices using the DCL command SET 
DEVICE/SERVED. For more information on the MSCP server and its 
functions, refer to the Guide to VAXclusters. 


11.15 SYSGEN Parameters Used in AUTOGEN Calculations 

The following tables list the SYSGEN parameters whose values AUTOGEN 
collects and (re)calculates in various operation phases. 


Table 11-5 Parameters Collected in OLDSITE1.DAT and 

Propagated to New System if Old Current Value 
exceeds Autogen's Calculated Value 



GBLPAGES 

MAXBUF 

GBLPAGFIL 

MAXPROCESSCNT 

GBLSECTIONS 

VIRTU ALP AGECNT 
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Table 11-6 Parameters Collected in OLDSITE2.DAT and 

Propagated to New System if Old Current Value 
Exceeds Old Default Value 


ACFLEXTCACHE 

CLISYMTBL 

DEFMBXNUMMSG 

PQL—BDIOLM 

PQL_DFILLM 

PQI_DWSQUOT A 

PQL_MBYTLM 
PQL _MWSDEF AULT 
PROCSECTCNT 


ACP—EXTLIMIT 

DEFMBXBUFQUO 

LRPSIZE 

PQL_DBYTLM 

PQL—DWSDEF AULT 

PQL_MASTLM 

PQL_MDIOLM 

PQL—MWSEXTENT 

SRPSIZE 


ACP_FIDCACHE 

DEFMBXMXMSG 

PQL_DASTLM 

PQL_DDIOLM 

PQL —DWSEXTENT 

PQL_MBIOLM 

PQL_MFILLM 

PQL_MWSQUOTA 


Table 11-7 Parameters Collected in OLDSITE3.DAT and 

Propagated to New System if Old Current Value 
Differs from Old Default Value 


ACP—BASEPRIO 

ACP_WRITEBACK 

CRDENABLE 

DISMOUMSG 

LAMAPREGS 

MVTIMEOUT 

PQL_DPRCLM 

PQL_MPRCLM 

SAVEDUMP 

TIMEPROMPTWAIT 

TTY_BUF 

TTY_PARITY 

TTY_SC ANDELT A 

TTY_TYPAHDSZ 

USER4 

XFMAXRATE 


ACP—DAT ACHECK 

BUGCHECKFATAL 

DEADLOCK_WAIT 

DUMPBUG 

MAXSYSGROUP 

PAGFILCNT 

PQL_DTQELM 

PQL—MTQELM 

SCSSYSTEMID 

TTY_ALT ALARM 

TTY_DIALTYPE 

TTY_PROT 

TTY_SILOTIME 

UAFALTERNATE 

USERD1 


ACP_SWAPFLGS 

BUGREBOOT 

DEFPRI 

EXTRACPU 

MOUNTMSG 

PQL_DCPULM 

PQL_MCPULM 

REALTIME _SPTS 

SWPFILCNT 

TTY—ALTYPAHD 

TTY_OWNER 

TTY_RSPEED 

TTY_SPEED 

USER3 

USERD2 
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Table 11-8 Version 4.4 Parameters Collected in OLDSITE4.DAT 
and Propagated to New System if Old Current Value 
Differs from Old Default Value 



ALLOCLASS 

DISK_QUORUM 

LNMPHASHTBL 

LNMSHASHTBL 

LOCKDIRWT 

PRCPOLINTERVAL 

QDSKINTERVAL 

QDSKVOTES 

QUORUM 

RECNXINTERVAL 

SCSNODE 

SCSSYSTEMIDH 

TAILORED 

TTY_DEFCHAR 

TTY_DEFCHAR2 

VOTES 




Table 11-9 Parameters Modified in AUTOGEN Calculations 


ACR—DIRCACHE 

ACP—MULTIPLE 

ACP—SYSACC 

FREEGOAL 

GBLPAGFIL 

IRPCOUNT 

LOCKIDTBL_MAX 

MAXPROCESSCNT 

MPW—WAITLIMIT 

PAGEDYN 

RESHASHTBL 

SRPCOUNT 

VAXCLUSTER 

WS_OPAO 


ACP_HDRCACHE 

ACP_QUOCACHE 

BALSETCNT 

FREELIM 

GBLSECTIONS 

IRPCOUNTV 

LRPCOUNT 

MPW_HILIMIT 

NPAGEDYN 

PFCDEFAULT 

SCSCONNCNT 

SRPCOUNTV 

VIRTU ALP AGECNT 


ACP_MAPCACHE 

ACP_SWAPFLGS 

BORROWLIM 

GBLPAGES 

GROWLIM 

LOCKIDTBL 

LRPCOUNTV 

MPW_LOLIMIT 

NPAGEVIR 

PFRATL 

SPTREQ 

SCSMWCNT 

WSMAX 
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Using BOOT58 on VAX-11 / 750 Systems 


This appendix explains how to bootstrap VAX-11/750 systems using the 
standalone BOOT58 program stored on the TU58 tape cartridge. 

In most cases it is quicker, easier, and the recommended procedure to 
bootstrap the system directly from a system disk. When you do this, however, 
the bootblock program must read and execute the boot block (block 0). If this 
block is corrupted, and the rest of the disk is intact, the only way to boot a 
VAX-11/750 system safely is to use standalone BOOT58. Later, you can use 
the Writeboot Utility (WRITEBOOT), described in Section A.2, to replace the 
bad boot block. 

The standalone BOOT58 program resides on the console TU58 tape cartridge 
and is used to supplement the console subsystem's bootstrapping functions. 
When you request a boot from the console TU58 tape cartridge (device 
DDAO), the console subsystem microcode reads the TU58 boot block (block 
0) into memory and executes it. The effect of executing the TU58 boot block 
is to load and transfer control to standalone BOOT58. 

Using standalone BOOT58, you can boot the system either in a conversational 
or nonstop mode. In a conversational boot, you are allowed to intervene with 
system parameter changes as the boot is progressing. The nonstop boot does 
not allow you this flexibility. 

The console TU58 tape cartridge contains two sets of bootstrap command 
procedures—a set of conversational procedures, and a set of nonstop 
procedures. To determine which procedures are available on your console 
volume, refer to Section 2.4. 

Table A-l summarizes BOOT58 commands. 

Table A-1 BOOT58 Commands 

Command Function 

BOOT [device-name] Bootstraps the system from the specified 

device. If you omit the device name, 
the system is bootstrapped using the 
default bootstrap command procedure 
(DEFBOO.CMD). Note that you cannot 
specify this command within a command 
procedure, and that you cannot use the 
name of a command procedure as a 
command qualifier. 
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Table A-1 (Cont.) BOOT58 Commands 

Command Function 


DEPOSIT [loc-qual, 
size-qual] location value 


EXAMINE [loc-qual, 
size-qual] location 


HELP 


LOAD file-spec 
[/ST ART :address] 


Deposits a value in the specified location. 
The location is interpreted according to the 
location and size qualifiers. The location 
qualifier can be expressed as follows: 

/G general register 

/I internal processor register 

/P physical memory 

The size qualifier can be expressed as 
follows: 

/B byte 

/W word 

/L longword 

If you do not specify the location and size 
qualifiers, the default values established by 
a previous command are used. 

Displays the contents of the specified 
location. The location is interpreted 
according to the location and size qualifiers. 
The location qualifier can be expressed as 
follows: 

/G general register 

/I internal processor register 

/P physical memory 

The size qualifier can be expressed as 
follows: 

/B byte 

/W word 

/L longword 

If you do not specify the location and size 
qualifiers, the default values established by 
a previous command are used. 

Displays the BOOT58 help file at the 
console terminal. You cannot specify this 
command within a command procedure. 

Loads a file from the bootstrap device into 
memory, starting at the address specified 
with the /START qualifier. If you omit the 
/START qualifier, the file is loaded into 
memory beginning at the first free address. 
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Table A-1 (Cont.) BOOT58 Commands 


Command 


Function 


START value 


@file-spec 


Transfers control to the value specified. 
You generally use this command with the 
LOAD command. 

Executes the name of the command 
procedure specified. You cannot specify 
a command procedure file specification 
of more than six characters, nor can you 
specify nested command procedures. 


A.1 Bootstrap Procedures 


You can select one of the following procedures to bootstrap your 
VAX-11/750 system using BOOT58: 

• Default 

• Conversational 

• Nonstop 

These procedures are described in the next sections. 


A. 1.1 Default Bootstrap 


To bootstrap the system using the default command procedure that you 
copied to the file DEFBOO.CMD, follow these steps: 

1 Shut down the system by executing the SHUTDOWN command 
procedure: 

$ <DSYS$SYSTEM: SHUTDOWN 

The command procedure prompts for the number of minutes until system 
shutdown, the reason for the shutdown, and whether to spin down the 
disks. 

2 In response to the statement, "SYSTEM SHUTDOWN COMPLETE - USE 
CONSOLE TO HALT THE SYSTEM," halt the processor by pressing 
CTRL/P. 

3 In response to the console prompt (> > > ), enter the following 
command: 


»> B DDAO 


Note: To prevent an automatic default booting, in cases where DEFBOO.CMD 
is already included on the TU58, use the command B/800 DDAO. 
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A.1.2 Conversational Bootstrap 

To do a conversational bootstrap using the standalone BOOT58 program, 
proceed as follows: 

1 Insert the console TU58 tape cartridge (part description: BE-T204F-ME 
TU58#1 VAX-11/750 Local Console) into the console drive. 

2 See that the rotary key switch on the processor control panel is set to 
LOCAL. 

3 Set the POWER-ON-ACTION switch to HALT. 

4 Press CTRL/P to obtain the console program prompt (> > > ). 

5 At the prompt, enter the following console BOOT command to boot the 
TU58 tape cartridge: 

»> B/800 DDAO 

Note: If you fail to add the /800 qualifier, the console program tries to 
execute DEFBOO.CMD. 

6 In response to the BOOT58> prompt, enter the name of a conversational 
bootstrap command procedure: 

B00T58> GDxyGEN 

@ Indicates that the rest of the line contains the name of a command 

procedure located on the console TU58 tape cartridge. 

x Indicates the device type of the desired bootstrap volume: 

B—RM03, RM80, RP05, RP06, RP07 
L—RL02 
M—RK07 
U—UDA 

y Indicates the unit number of the desired bootstrap device volume. 

Specify a number in the range of 0 through 7. 

When SYSBOOT is ready to accept commands, it prompts as follows: 

%y. 

SYSB00T> 

The two percent signs (%%) that appear above the SYSBOOT > prompt 
indicate a successful verification of the microcode. You can now issue any of 
the commands listed in Table 4-1. 

If your system will not boot, you can enter the following sequence of 
SYSBOOT commands after the SYSBOOT > prompt to boot using default 
system parameter values: 

SYSB00T> USE DEFAULT 
SYSB00T> CONTINUE 

The following example shows a conversational bootstrap procedure on a 
VAX-11/750 system using the standalone BOOT58 program. During the 
procedure, the user sets the value of the system parameter WSMAX to 
512. Note that before displaying the BOOT58> prompt, the VAX-11/750 
responds with a double percent sign to indicate successful verification of the 
microcode. 
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»> B/800 DDAO 

n 

B00T58> ODMOGEN 


DMO CONVERSATIONAL BOOT COMMAND FILE - DMOGEN 

BOOT FROM DMO AND STOP IN SYSBOOT TO ALTER PARAMETER VALUES 


D/G 0 1 
D/G 1 FFEOOO 
D/G 2 3FF20 
D/G 3 0 
D/G 4 0 
D/G 5 1 
D/G E 200 

LOAD VMB.EXE/START:200 
START 200 

SYSBOOT> SET WSMAX 512 
SYSBOOT> CONTINUE 


! CARTRIDGE DISK 
! BASE OF UNIBUS I/O PAGE 
! CSR ADDRESS OFFSET 
! CONTROLLER UNIT = 0 
! BOOT BLOCK LBN (UNUSED) 

! SOFTWARE BOOT FLAGS (CONVERSATIONAL) 
! ADDRESS OF WORKING MEMORY + ~X200 
! LOAD PRIMARY BOOTSTRAP 
! START PRIMARY BOOTSTRAP 


VAX/VMS Version 4.4 15-APR-1986-14:20:50.15 


7.7.y.7.7.y.7.7.7.7.y. OPCOM, 15-APR-1986-14:20:50.15 VWWWIXVL 
Logfile has been initialized by operator _OPAO: 

Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1 

7.SET-I-INTSET, login interactive limit = 64, Current interactive value = 0 
SYSTEM job terminated at 15-APR-1986-14:20:50.15 


A. 1.3 Nonstop Bootstrap 

If you want to bootstrap the system without stopping to change parameters, 
follow steps 1 through 5 for the conversational bootstrap procedure described 
in the previous section. Then, in response to the BOOT58> prompt, enter 
the name of a nonstop bootstrap command procedure in the following format: 

B00T58> ODxyBOO.CMD 

@ Indicates that the rest of the line contains the name of a command 

procedure located on the console TU58 cartridge. 

x Indicates the device type of the desired bootstrap device volume: 

B—RM03, RM80, or RP06 
M—RK07 

y Indicates the unit number of the desired bootstrap volume. Specify a 

number in the range of 0 through 7. 

If you use this form (that is, @DxyBOO.CMD), the contents of the command 
procedure are displayed on the console terminal. 

The following example shows a nonstop bootstrap procedure on a 
VAX-11/750 system using the standalone BOOT58 program. Note that 
before displaying the BOOT58> prompt, the VAX-11/750 responds with a 
double percent sign to indicate successful verification of the microcode. 
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»> B DDAO 

n 

B00T58> QDM0B00.CMD 


DM0 BOOT COMMAND FILE - DMOBOO.CMD 


D/G 0 1 


CARTRIDGE DISK 

BASE OF UNIBUS I/O PAGE 

CSR ADDRESS OFFSET 

CONTROLLER UNIT = 0 

BOOT BLOCK LBN (UNUSED) 

SOFTWARE BOOT FLAGS 

ADDRESS OF WORKING MEMORY + ~X200 


D/G 1 FFEOOO 
D/G 2 3FF20 


D/G 3 0 
D/G 4 0 
D/G 5 0 


D/G E 200 


LOAD VMB.EXE/START:200 ! LOAD PRIMARY BOOTSTRAP 


START 200 


START PRIMARY BOOTSTRAP 


VAX/VMS Version 4.4 15-APR-i986-14:20:50.15 

mxmuu OPCOM, 15-APR-1986-14: 20: 50.15 XXXXXXltm 
Logfile has been initialized by operator _OPAO: 

Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1 

'/.SET-I-INTSET, login interactive limit = 64, Current interactive value = 0 
SYSTEM job terminated at 15-APR-1986-14:20:50.15 


A. 2 The Writeboot Utility 


This section discusses the Writeboot Utility (WRITEBOOT), which writes a 
boot block on a bootable disk. 

The normal bootstrap operation on the VAX-11/750 is done from the boot 
block (block 0) of the system disk. If this block is corrupted, the system can 
only be bootstrapped from the TU58. Once the system is running again, the 
bad boot block can be rewritten by using WRITEBOOT. 

Note: The L0G_I/0 privilege is required to use WRITEBOOT. 

To invoke WRITEBOOT, type the following command at the DCL prompt: 

$ RUN SYS$SYSTEM:WRITEBOOT 

WRITEBOOT will prompt for input. Prompts and recommended responses 
follow. 

Target system device (and boot file if not VMB.EXE):? 

Enter the name of the device on which you want to rewrite the boot block 
(DMAO for example). 

Note: The boot file must be on the target disk. 

The target system device should be specified like any VAX/VMS disk device 
(ddcu): 

dd is the code name for the device type 
c is the controller designation 
u is the unit number 

For example, DMAO would be an RK07 on RK611 controller A, device 
number 0. If you want to use a boot file other than SYS$SYSTEM:VMB.EXE, 
you must provide the full file specification, including device and directory. 

Enter VBN of boot file code (default is one): 
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If you are rewriting the boot block, press RETURN. 

Enter load address of primary bootstrap in HEX (default is 200): 

Again, if you are rewriting the boot block, press RETURN. 

WRITEBOOT will then write the boot file that you specified in the first line, 
to the address that you entered in the third line. 

The Writeboot Utility may issue one or more of the following error 
messages: 

You lack LOG—IO privilege 

Explanation: This message means you do not have the correct privilege to 
use WRITEBOOT. 

You lack READ and/or WRITE access to TARGET DEVICE. DISMOUNT and 
REMOUNT 

Explanation: This message means that access to the target device is limited. 
Check the WRITE PROTECT button. 

VBN must be > = 1 

Explanation: This message means you cannot specify a zero as the virtual 
block number (VBN). 
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This appendix describes the Computer Interconnect (Cl) and System 
Communications Services (SCS) including information on trouble-shooting 
and repairs. Information on Cl entries in the system error log and on 
corrective actions to take when errors occur is also provided. 


B.1 Cl Port and System Communications Services Operation 

The following sections describe the Cl port and the operation of System 
Communications Services (SCS). 


B. 1.1 Cl Port Polling and Virtual Circuits 

Shortly after VAX/VMS boots, the Cl port driver begins configuration polling 
in order to discover other active ports on the Cl. Normally the poller runs 
every five seconds (the default value of SYSGEN parameter PAPOLLINT.) In 
the first polling pass, port numbers 0 through 15 are probed over cable path 
A; on the second pass port numbers 0 through 15 are probed over path B; on 
the third pass path A is probed again, and so on. 

The poller probes by sending request id (REQID) packets to all possible port 
numbers, including itself. Active ports receiving the REQIDs return id packets 
(IDREC) to the port issuing the REQID. A port may respond to a REQID 
whether or not the system attached to the pirt is running. 

Once a pair of ports and port drivers has successfully exchanged id packets, 
the port drivers perform a start handshake. They exchange datagrams 
containing information about the systems such as the type of CPU (for 
example, V780, V750, HSC) and the operating system version. If this 
exchange is successful, then each system declares a virtual circuit (VC) 
open. An open VC is prerequisite to all other activity. Each port supports up 
to 16 VCs. 


B. 1.2 System Communications Services Connections 

System services such as the disk class driver, the VAXcluster connection 
manager, and the MSCP disk server communicate between systems with a 
protocol called System Communications Services (SCS). Primarily, SCS is 
responsible for the formation and breaking of intersystem process connections 
and for flow control of message traffic over those connections. In VAX/VMS 
Version 4.4, SCS is implemented in the Cl port driver and in a loadable piece 
of the system called SCSLOA.EXE (loaded automatically during initialization). 

When a VC has been opened, a VAX/VMS system periodically probes a 
remote system for system services that it may be offering. The SCS directory 
service, which makes known other services that its system is offering, is 
always present on both VAX/VMS and HSC systems. As system services 
discover their counterparts on other systems, they establish SCS connections 
to each other. These connections are full duplex and are associated with a 
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particular VC. Multiple connections are typically associated with a virtual 
circuit. 


B.1.3 Failures 


Taken together, SCS, the Cl port driver, and the Cl port itself support a 
hierarchy of communications paths. Working up from the most fundamental 
level there are: 

• The physical wires (two pairs of transmit and receive) Path A transmit 
and receive and Path B transmit and receive. Normally, traffic is sent by 
VAX/VMS in automatic path select mode and the port chooses the free 
path or, if both are free, an arbitrary path (implemented in the cables, star 
coupler, and managed by the port). 

• The port-to-port virtual circuit (implemented partly in the Cl port and 
partly in system software). 

• The connections (implemented in system software). 

Failures can occur at each communications level and in each component. 
Failures at one level translate into failures at lower levels as follows: 

• Wires. One of Path A or B can fail and the VC remains intact. All traffic 
is directed over the remaining good path. If the wire is repaired, the repair 
is detected automatically by port polling, and done to all ports. 

• Virtual circuit. If neither Path A nor B works between a pair of ports, then 
the VC fails and is closed. Path failures are discovered either by 

— Attempting to send normal traffic with the port reporting that neither 
path yielded transmit success 

— The poller sending REQIDs over Path A and B periodically when both 
paths are nonfunctional 

When a whole VC fails, every SCS connection on it fails. The software 
automatically reestablishes connections when the VC is reestablished. 
Normally, reopening a VC takes about 10 seconds after the source of the 
problem disappears. 

• Port. If a port fails, then all the VCs to that port fail and all SCS 
connections on those VCs fail. If the port is successfully reinitialized, 

VCs and connections will be reestablished automatically. Normally, 
reinitialization and connection reestablishment takes about 10 seconds. 

• Connection. When the software protocols fail in some way or, in some 
instances, when the software thinks it detects a hardware malfunction, a 
connection is disconnected. Other connections are normally unaffected, as 
is the VC. 

• System. If a whole system fails by operator shutdown, bugcheck, or halt 
and reboot, then its port fails and all other systems on the Cl note this as 
failures of their VCs to the port on this system. 

One interesting situation is the case where a system halts, but no INIT 
(11/750) or UNJAM (11/780) is done. The port remains running and 
other systems on the Cl cannot detect the failed system. The VAXcluster 
services on the failed system appear simply to be hung, because the port is 
an independent processor and continues to handle incoming traffic and to 
respond to REQIDs. (The same effect is achieved if the failed system is hung 


B—2 





Technical Note on VAX/VMS Cl 


at IPL 8 or above.) VAX Cl ports normally run with a sanity timer enabled, 
which puts the port into an uninitialized state detectable by other nodes as a 
failed VC if the host appears to be hung for 100 seconds. This interval will 
be reduced with the next release of Cl port microcode. 


B.2 Trouble-Shooting 

This section contains advice on how to determine which system in the 
VAXcluster and which component in that system is causing errors. These 
determinations can often be made without interrupting timesharing activity 
on systems in the VAXcluster. 


B.2.1 Adding Nodes to a VAXcluster 

Before you bring up as a part of a VAXcluster a system that is new, just 
repaired, or suspected of having a problem, you should verify that the system 
runs correctly on its own. Although this precaution cannot guarantee that 
VAXcluster software will run correctly over the Cl, it can help track down 
errors if they should occur. 

If only an HSC disk is available for booting, you will be unable to verify the 
system on its own and you can proceed to step 2. If a local MASSBUS or 
UNIBUS disk is available for booting, you can use step 1 to boot your system 
almost entirely in isolation from Cl activity. 

1 Perform a conversational boot. While running SYSBOOT, suppress port 
activity with the following commands: 

SYSB00T> SET PAN0P0LL 1 
SYSB00T> SET VAXCLUSTER 0 

Having booted in this way, you can run any desired tests to verify the 
system, independent of the CL 

Also, since the above SYSGEN parameters still permit the Cl port to be 
autoconfigured and initialized, you can verify minimal Cl port capabilities. 
Use the following command to check that the port is initialized and is on 
line: 

$ SHOW DEVICE PAAO 

The device should be on line and have zero errors. If it has errors and/or 
is off line, check the error log. If the port failed to initialize because of 
device errors, read the section of the VAX/VMS Release Notes Version 4.4 
concerning Cl port microcode revision levels. Corrupted port microcode 
files and incompatible microcode files and proms are two reasons for 
continuous port errors upon initialization. 

2 When the system has been verified (or if no local boot device is 
available), boot the system in a VAXcluster from its normal boot device. 
Remember to do a conversational boot the first time and specify a unique 
SCSSYSTEMID and SCSNODE for the system. Also, if necessary, restore 
PANOPOLL to its default value of 0 and set VAXCLUSTER =1 (if the 
system will be joining a VAXcluster). 

As the system boots, watch the OP AO terminal for %CNXMAN messages 
that indicate that this system is discovering other systems and forming 
connections to their connection managers. (See the Guide to VAXclusters, 
Appendix B, for detailed descriptions of these messages.) Also, note any 


B—3 







Technical Note on VAX/VMS Cl 


Cl port error messages on OP AO. These are documented in section B.7 of 
this appendix. 

If the system fails to come all the way up so that you can log in and 
use it, but no obvious error information is on device OPAO, then check 
the status of the failing system from other VMS nodes using the SHOW 
CLUSTER/CONTINUOUS command of the Show Cluster Utility. See the 
VAX/VMS Show Cluster Utility Reference Manual for more detail. 

3 In diagnosing these problems, it is useful to tailor the SHOW CLUSTER 
report by the command ADD CIRCUIT CABLE_ST. This command adds 
a class of information about all the virtual circuits as seen from the system 
on which you are running SHOW CLUSTER. Primarily, you are checking 
whether there is a virtual circuit in the OPEN state to the failing system. 
Common causes of failure to open a VC and keep it open are: 

• Port errors on one side or the other 

• Some cabling errors 

• A port set off line due to software problems 

• Insufficient nonpaged pool available on both sides 

• Failure to set the SYSGEN parameters SCSNODE, SCSSYSTEMID, 
PAMAXPORT, PANOPOLL, PASTIMOUT, and PAPOLLINT correctly 

4 If no VC is open to the failing system, check the bottom of the SHOW 
CLUSTER display for circuit information to the port of the failing system. 
VCs in partially open states are placed at the bottom of the display. If the 
circuit is there in a state other than OPEN, communications between the 
local port and remote port are taking place and the failure is probably at 
a higher level in the communications than in port or cable hardware. 
Secondarily, check that both Paths A and B are good to the failing 
port, although the loss of one path should not prevent a system from 
participating in a VAXcluster. 

5 Run SHOW CLUSTER from each running system in the VAXcluster to see 
that each system's view of the failing system is consistent with every other 
system's view. If all the running systems have a consistent view of the 
failing system, chances are the problem is in the failing system. If, on the 
other hand, only one of several running systems thinks the newcomer is 
failing, then perhaps the problem is in that one running system. 


B.2.2 Crossed Cables and Loopback Datagrams 

Whenever the configuration poller finds that no port-to-port virtual circuits 
are open and that no handshake procedures are currently opening virtual 
circuits, the poller analyzes its environment. It does so by using the send- 
loopback-datagram facility of the Cl port. 

The send-loopback-datagram facility tests the connections between the Cl 
port and the Star coupler by routing a message across them. The messages 
are called loopback datagrams. (The port processes other self-directed 
messages without using the Star coupler or external cables.) 

The configuration poller makes entries in the error log whenever it detects 
a change in the state of a circuit. Note, however, that it is possible for 
two changed-to-failed-state messages to be entered in the log without an 
intervening changed-to-succeeded-state message. Such a series of entries 
means that the circuit state continues to be faulty. 
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The following paragraphs discuss various incorrect Cl cabling configurations 
and the entries made in the error log when these configurations exist. 
Figure B-l shows a two-node configuration with all cables correctly 
connected. 

Figure B-1 A Correctly Connected Two-Node Cl VAXcluster 



ZK-1924-84 


Figure B-2 Crossed Cl Cable Pair 



ZK-1925-84 


Figure B-2 shows a Cl VAXcluster with a pair of crossed cables. If a pair of 
transmitting cables or a pair of receiving cables is crossed, a message sent on 
TA is received on RB, and a message sent on TB is received on RA. This is 
a hardware error condition from which the port cannot recover. An entry is 
made in the error log to say that a single pair of crossed cables exists. The 
entry contains the lines 

DATA CABLE(S) CHANGE OF STATE 

PATH 1. LOOPBACK HAS GONE FROM GOOD TO BAD 

If this situation exists, you can correct it by reconnecting the cables properly. 
The cables could be misconnected in several places. The coaxial cables that 
connect the port boards to the bulkhead cable connectors can be crossed, 
or the Ethernet cables can be misconnected to the bulkhead or the STAR 
coupler. 

The information in Figure B-2 can be represented more simply. Configuration 
1 shows the cables positioned as in Figure B-2, but it does not show the 
star coupler or the nodes. The letters LOC and REM indicate the pairs of 
transmitting (T) and receiving (R) cables on the local and remote nodes, 
respectively. 


B—5 






































Technical Note on VAX/VMS Cl 


Configuration 1 


T x 

= R 

R = 

= T 

LOC 

REM 


The pair of crossed cables causes loopback datagrams to fail on the local 
node, but succeed on the remote node. Crossed pairs of transmitting cables 
and crossed pairs of receiving cables cause the same behavior. 

Note that only an odd number of crossed-cable pairs causes these problems. 
If an even number of cable pairs is crossed, communications succeed. An 
error log entry is made in some cases, however, and the contents of the entry 
depends on which pairs of cables are crossed. 

Configuration 2 shows two-node VAXclusters with the combinations of two 
pairs of crossed-cable pairs. These crossed pairs cause the following entry to 
be made in the error log of the node that has the cables crossed: 

DATA CABLE(S) CHANGE OF STATE 

CABLES HAVE GONE FROM UNCROSSED TO CROSSED 

Loopback datagrams succeed on both nodes, and communications are 
possible. 

Configuration 2 


T x 

= R 

T = 

x R 

R x 

= T 

R = 

x T 

LOC 

REM 

LOC 

REM 


Configuration 3 shows the possible combinations of two pairs of crossed 
cables that cause loopback datagrams to fail on both nodes in the cluster. 
Communications can take place between the nodes nevertheless. An entry 
stating that cables are crossed is made in the error log of each node. 


Configuration 3 

T x = R 

T = 

x R 

R * 

x T 

R x 

= T 

LOC 

REM 

LOC 

REM 


Configuration 4 shows the possible combinations of two pairs of crossed 
cables that cause loopback datagrams to fail on both nodes in the cluster, but 
allow communications. No entry stating that cables are crossed is made in 
the error log of either node. 

Configuration 4 


T x 

x R 

T = 

= R 

R = 

= T 

R x 

x T 

LOC 

REM 

LOC 

REM 


Configuration 5 shows the possible combinations of three pairs of crossed 
cables. In each case, loopback datagrams fail on the node that has only one 
crossed pair of cables. Loopback datagrams succeed on the node with both 
pairs crossed. No communications are possible. 
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Configuration 5 


T x 

x R 

T x 

= R 

T = 

x R 

T x 

x R 

R x 

= T 

R x 

x T 

R x 

x T 

R = 

x T 

LOC 

REM 

LOC 

REM 

LOC 

REM 

LOC 

REM 


If all four cable pairs between two nodes are crossed, communications 
succeed, loopback datagrams succeed, and no crossed-cable message entries 
are made in the error log. Such a condition might be detected by noting error 
log entries made by a third system in the VAXcluster, but only if the third 
node has one of the crossed-cable cases described above. 


B.3 Repairing Cables 

This section describes some ways in which DIGITAL Field Service can make 
repairs on a running system. This information is provided to aid system 
managers in scheduling repairs. 

In order for the software to survive cable-checking activities or cable- 
replacement activities, you must be sure that at least Path A or Path B is 
intact at all times between each port and every other port in the VAXcluster. 

You can, for example, remove Path A and Path B in turn from a particular 
port to the Star coupler. To make sure that the configuration poller finds a 
path that was previously faulty but is now without fault, you must time your 
operations as follows: 

1 Remove Path B. 

2 After the poller has discovered that Path B is faulty, reconnect Path B. 

3 Wait two poller intervals (or run SHOW CLUSTER) to make sure 
that the poller has reestablished Path B. Or, run SHOW CLUSTER 
/CONTINUOUS and ADD CIRCUITS, CABLE _ST; wait until SHOW 
CLUSTER tells you that Path B has been regained. 

4 Remove Path A. 

5 After the poller has discovered that Path A is faulty, reconnect Path A. 

6 Wait two poller intervals to make sure that the poller has reestablished 
Path A. 

If both paths are lost at the same time, then the port-to-port virtual circuits 
are lost between the port with the broken cables and all other ports in the 
VAXcluster. This will in turn result in loss of SCS connections over the 
broken virtual circuits. However, recovery from this situation is automatic 
after an interruption in service on the affected node. The length of the 
interruption varies but is usually about two poller intervals or 10 seconds at 
the default SYSGEN parameter settings. 
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B.4 Analyzing VAXcluster Error Log Entries 

Part of anticipating and avoiding problems is to monitor the activities of the 
system; important events are recorded in the error log. From the total error 
count, displayed by the DCL command SHOW DEVICE PA, you can tell if 
errors have been increasing. If so, you should examine the error log. 

The ANALYZE/ERROR—LOG command invokes the Error Log Utility 
to report the contents of an error log file. For more information, see the 
VAX/VMS Error Log Utility Reference Manual. 

Note: Some error log entries are informational only, and require no action. 

If you shut down a system in the VAXcluster, for example, all other 
systems in the cluster that have open port-to-port virtual circuits between 
themselves and the shut down system make entries in their error logs. 
Such systems record up to three errors for the event: Path A got no 
response. Path B got no response, the virtual circuit is being closed. These 
messages are normal and reflect the change of state in the circuits to the 
shut down system. 

On the other hand, some error log entries are made for problems that degrade 
operation, or for nonfatal hardware problems. VMS might continue to run 
satisfactorily under these conditions. The purpose of detecting these problems 
early is to prevent nonfatal problems (such as loss of a single path) from 
becoming serious problems (such as loss of both paths). 


B.5 Error Log Entry Formats 

Errors and other events on the Cl cause the port driver to enter information 
into the system error log. The two formats used for Cl error log entries are 
the device-attention format and the logged-message format. This section 
describes those formats. 

Device-attention entries record events that, in general, are indicated by the 
setting of a bit in a hardware register. Logged-message entries record the 
receipt of a message packet that contains erroneous data or that signals an 
error condition. 


B.5.1 Device-Attention Entries 

Example B-l shows a device-attention entry. The left column gives the 
name of a device register or a memory location, the center column gives the 
value contained in that register or location, and the right column gives an 
interpretation of that value. 
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Example B—1 Device-Attention Entry 


**************************** ENTRY 


83. 


**************************** 


o 


ERROR SEQUENCE 10. 

DEVICE ATTENTION, 17-MAY-1986 17:11:33.99 

KA780 REV #10. SERIAL #10. 

Cl SUB-SYSTEM, STAR$PAA0: - PORT POWER DOWN 


LOGGED ON SID 0150400A 


MFG PLANT 0. 


0 

0 

O 


CNFGR 00800038 

ADAPTER IS Cl 
ADAPTER POWER-DOWN 

PMCSR OOOOOOCE 

MAINTENANCE TIMER DISABLE 
MAINTENANCE INTERRUPT ENABLE 
MAINTENANCE INTERRUPT FLAG 
PROGRAMMABLE STARTING ADDRESS 
UNINITIALIZED STATE 


PSR 

80000001 

RESPONSE QUEUE AVAILABLE 
MAINTENANCE ERROR 


PFAR 

00000000 



PESR 

00000000 



PPR 

03F80001 



UCB$B_ERTCNT 

32 

50. RETRIES REMAINING 

© 

© 

UCB$B_ERTMAX 

32 

50. RETRIES ALLOWABLE 


UCB$L_CHAR 

0C450000 

SHAREABLE 

AVAILABLE 

ERROR LOGGING 

CAPABLE OF INPUT 

CAPABLE OF OUTPUT 


UCB$W_STS 

0010 

ONLINE 


UCB$W_ERRCNT 

000B 

11. ERRORS THIS UNIT 

Q 


O The first two lines are the entry heading. These lines contain the number 
of the entry in this error log file, the sequence number of this error, and 
the identification number (SID) of this system's CPU. Each entry in the 
log file contains such a heading. 

0 The next line contains the entry type, the date, and time. 

© The next line contains the processor type (KA780), the hardware revision 
number of the CPU (REV #10), the serial number of the CPU (SERIAL 
#10), and the plant number (0). 

O The line Cl SUB-SYSTEM, STAR$PAA0: - PORT POWER DOWN 
contains the name of the subsystem and the device that caused the 
entry, and the reason for the entry. The Cl subsystem's device PAAO on 
node STAR was powered down. 

The next 15 lines contain the names of hardware registers in the port, 
their contents, and interpretations of those contents. See the CI780/CI750 
User's Guide for a description of all the Cl port registers. 

The Cl port can recover from many errors, but not all. When an error 
occurs from which the Cl cannot recover, the port notifies the port driver. 
The port driver logs the error and attempts to reinitialize the port. If 
the port fails after 50 such initialization attempts, the driver takes it off 
line unless the system disk is connected to the failing port or this system 
is supposed to be a VAXcluster member. If the Cl port is required for 
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system disk access or VAXcluster participation and all 50 reinitialization 
attempts have been used, then the system bugchecks with a CIPORT-type 
bugcheck. Once a Cl port is off line, you can put the port back on line 
only by rebooting the system. 

© The UCB$B_ERTCNT field contains the number of reinitializations that 
the port driver can still attempt. The difference between this value and 
UCB$B_ERTMAX is the number of reinitializations already attempted. 

© The UCB$B_ERTMAX field contains the maximum number of times the 
port can be reinitialized by the port driver. 

© The UCB$W_ERRCNT field contains the total number of errors that have 
occurred on this port since it was booted. This total includes both errors 
that caused reinitialization of the port and errors that did not. 


B.5.2 Logged-Message Entries 

Logged-message entries are made when the Cl port receives a response that 
contains either data that the port driver cannot interpret, or an error code in 
the status field of the response. 

Example B-2 shows a logged-message entry with an error code in the status 
field PPD$B_STATUS. 
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Example B-2 Logged-Message Entry 


******************* ********* ENTRY 3. *************************0 

ERROR SEQUENCE 3. LOGGED ON SID 01188542 

ERL$LOGMESSAGE, 17-MAY-1986 13:40:25.13 © 

KA780 REV #3. SERIAL #1346. MFG PLANT 15. © 

Cl SUB-SYSTEM, STAR$PAA0: © 

DATA CABLE(S) STATE CHANGE - PATH #0. WENT FROM GOOD TO BAD © 

LOCAL STATION ADDRESS, 000000000002 (HEX) © 


LOCAL SYSTEM ID. 

000000000001 

(HEX) 

© 

REMOTE STATION ADDRESS. 000000000004 (HEX) 

© 

REMOTE SYSTEM ID, 

0000000000A9 

(HEX) 

© 

UCB$B_ERTCNT 

32 

50. RETRIES REMAINING 

© 

UCB$B_ERTMAX 

32 

50. RETRIES ALLOWABLE 


UCB$W_ERRCNT 

0001 

1. ERRORS THIS UNIT 

© 

PPD$B_P0RT 

04 

REMOTE NODE #4. 

© 

PPD$B_STATUS 

A5 

FAIL 

PATH #0., NO RESPONSE 

PATH #1., "ACK" OR NOT USED 
NO PATH 


© 

PPD$B_0PC 

05 

IDREQ 


PPD$B_FLAGS 

03 

RESPONSE QUEUE BIT 

SELECT PATH #0. 

© 

"Cl" MESSAGE 



© 


00000000 
00000000 
80000004 
0000FE15 
4F503000 
00000507 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 


© The first two lines are the entry heading. These lines contain the number 
of the entry in this error log file, the sequence number of the error, and 
the identification number (SID) of the system's CPU. Each entry in the log 
file contains a heading. 

© The next line contains the entry type, the date, and time. 

© The next line contains the processor type (KA780), the hardware revision 
number of the CPU (REV #3), the serial number of the CPU (SERIAL 
#1346), and the plant number (15). 

© The line Cl SUB-SYSTEM, STAR$PAA0: contains the name of the 
subsystem and the device that caused the entry. 
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© The next line gives the reason for the entry (one or more data cables have 
changed state), and a more detailed reason for the entry. Path 0, which 
the port used successfully before, cannot be used now. 

Note: ANALYZE/ERROR—LOG uses the notation path 0 and path 1; cable 
labels use the notation path A (=0) and path B (=1). 

© The local © and remote © station addresses are the port numbers (range 
0-15) of the local and remote ports. The port numbers are set in hardware 
switches by field service. The local © and remote © system IDs are the 
SCS system IDs set by the SYSGEN parameter SCSSYSTEMID for the 
local and remote VAX systems. For HSCs, the system ID is set with the 
HSC console. 

© The rest of the entry, which consists of the entry fields that begin with 
UCB$, gives information on the contents of the unit control block (UCB) 
for this Cl device. 

The following fields, which begin with PPD$, are fields in the message 
packet that the local port has received. 

® PPD$B_PORT contains the station address of the remote port. In a 
loopback datagram, however, this field contains the local station address. 

© The PPD$B_STATUS field contains information on the nature of the 
failure that occurred during the current operation. When the operation 
completes without error, ERF prints the word NORMAL beside this field; 
otherwise, ERF decodes the error information contained in 
PPD$B_STATUS. Here a NO PATH error occurred because of a lack of 
response on path 0, the selected path. 

© The PPD$B_OPC field contains the code for the operation that the port 
was attempting when the error occurred. The port was trying to send a 
request-for-id message. 

© The PPD$B_FLAGS field contains bits that indicate, among other things, 
the path that was selected for the operation. 

© The "Cl" MESSAGE is a hexadecimal listing of bytes 16 through 83 
(decimal) of the response (message or datagram). Since responses are of 
variable length depending upon the port opcode, bytes 16 through 83 may 
contain either more or fewer bytes than actually belong to the message. 
Here the request-for-id contains no information in bytes 16 through 83. 


B.6 Error Log Entry Descriptions 

This section describes error log entries. Each entry below is followed by a 
brief description of what the Cl port driver does, and the suggested action a 
system manager should take. In cases where Software Performance Reports 
with crash dumps are requested, it is important to capture the crash dumps 
as soon as possible after the error. Note that path A and path 0 are the same 
path, and that path B and path 1 are the same path. 

BIIC FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device offline. 

User Action: Call DIGITAL Field Service. 
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CI PORT TIMEOUT 

The CI port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device offline. 

User Action: First, increase the SYSGEN parameter PAPOLLINTERVAL. 

If the problem disappears and you are not running privileged user-written 
software, submit an SPR. Otherwise, call DIGITAL Field Service. 

11/750 CPU MICROCODE NOT ADEQUATE FOR PORT 

The CI port driver: Sets the port off line with no retries attempted. In 
addition, if this port is needed because the system is booted from an HSC or 
is participating in a VAXcluster, the system bugchecks with a UCODEREV 
code bugcheck. 

User Action: Read the VAX/VMS Release Notes Version 4.4 section on the CI 
port driver for information on required CPU microcode revisions. Call Field 
Service if necessary. 

PORT MICROCODE REV NOT CURRENT, BUT SUPPORTED 

The CI port driver: Detected that the microcode is not at the current level, 
but will continue normally. This error is logged as a warning only. 

User Action: Contact Field Service when convenient to have the microcode 
updated. 

PORT MICROCODE REV NOT SUPPORTED 

The CI port driver: Sets the port off line without attempting any retries. 

User Action: Read the VAX/VMS Release Notes Version 4.4 for information on 
the required CI port microcode revisions. Contact Field Service if necessary. 

DATA CABLE(S) STATE CHANGE 

CABLES HAVE GONE FROM CROSSED TO UNCROSSED 
The CI port driver: Logs this event. 

User Action: No action needed. 

DATA CABLE(S) STATE CHANGE 

CABLES HAVE GONE FROM UNCROSSED TO CROSSED 
The CI port driver: Logs this event. 

User Action: Check for crossed-cable pairs. See Section B.2. 

DATA CABLE(S) STATE CHANGE 
PATH 0. WENT FROM BAD TO GOOD 

The CI port driver: Logs this event. 

User Action: No action needed. 

DATA CABLE(S) STATE CHANGE 
PATH 0. WENT FROM GOOD TO BAD 

The CI port driver: Logs this event. 

User Action: Check path A cables to see that they are not broken or 
improperly connected. 
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DATA CABLE(S) STATE CHANGE 

PATH 0. LOOPBACK IS NOW GOOD, UNCROSSED 

The Cl port driver: Logs this event. 

User Action: No action needed. 

DATA CABLE(S) STATE CHANGE 

PATH 0. LOOPBACK WENT FROM GOOD TO BAD 

The Cl port driver: Logs this event. 

User Action: Check for crossed-cable pairs or faulty Cl hardware. See 
Section B.2. 

DATA CABLE(S) STATE CHANGE 
PATH 1. WENT FROM BAD TO GOOD 

The Cl port driver: Logs this event. 

User Action: No action needed. 

DATA CABLE(S) STATE CHANGE 
PATH 1. WENT FROM GOOD TO BAD 

The Cl port driver: Logs this event. 

User Action: Check path B cables to see that they are not broken or 
improperly connected. 

DATA CABLE(S) STATE CHANGE 

PATH 1. LOOPBACK IS NOW GOOD, UNCROSSED 

The Cl port driver: Logs this event. 

User Action: No action needed. 

DATA CABLE(S) STATE CHANGE 

PATH 1. LOOPBACK WENT FROM GOOD TO BAD 

The Cl port driver: Logs this event. 

User Action: Check for crossed-cable pairs or faulty Cl hardware. See 
Section B.2. 

DATAGRAM FREE QUEUE INSERT FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
and 8800) contention. 

DATAGRAM FREE QUEUE REMOVE FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures, or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
and 8800) contention. 
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FAILED TO LOCATE PORT MICRO-CODE IMAGE 

The Cl port driver: Marks device off line and makes no retries. 

User Action: Make sure console volume contains the microcode file 
CI780.BIN, and then reboot the system. 

HIGH PRIORITY COMMAND QUEUE INSERT FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
8800) contention. 

MSCP ERROR LOGGING DATAGRAM RECEIVED 

The Cl port driver: Upon receipt of an error message from the HSC, the 
port driver logs the error and takes no other action. It is recommended that 
you disable the sending of HSC informational error log datagrams with the 
appropriate HSC console command. Informational error log datagrams take 
considerable space in the error log data file. 

User Action: They are useful to read only if they are not captured on the 
HSC console for some reason (for example, the HSC console ran out of 
paper.) This logged information is a duplicate of the messages logged on the 
HSC console. 

INAPPROPRIATE "SCA" CONTROL MESSAGE 

The Cl port driver: Closes the port-to-port virtual circuit to the remote port. 

User Action: Submit a Software Performance Report to DIGITAL including 
the error logs and the crash dumps from the local and remote systems. 

INSUFFICIENT NON-PAGED POOL FOR INITIALIZATION 

The Cl port driver: Marks device off line and makes no retries. 

User Action: Reboot the system with a larger value for NPAGEDYN or 
NPAGEVIR. 

LOW PRIORITY CMD QUEUE INSERT FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
and 8800) contention. 

MESSAGE FREE QUEUE INSERT FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
and 8800) contention. 
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MESSAGE FREE QUEUE REMOVE FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
and 8800) contention. 

MICRO-CODE VERIFICATION ERROR 

The Cl port driver: Detected an error while reading the microcode that it 
just loaded into the port. The driver attempts to reinitialize the port; after 50 
failing attempts, it marks the device off line. 

User Action: Call DIGITAL Field Service. 

NO PATH-BLOCK DURING "VIRTUAL CIRCUIT" CLOSE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Submit a Software Performance Report to DIGITAL including 
the error log and a crash dump from the local system. 

NO TRANSITION FROM UNINITIALIZED TO DISABLED 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. 

PORT ERROR BIT(S) SET 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: For Cl microcode version 7 or later, a maintenance timer 
expiration bit may mean that the PASTIMOUT SYSGEN parameter is set too 
low, especially if the local node is running privileged user-written software. 
For all other bits, call DIGITAL Field Service. 

PORT HAS CLOSED "VIRTUAL CIRCUIT" 

The Cl port: Closes the virtual circuit that the local Cl port opened to the 
remote port. 

User Action: Check the PPD$B_STATUS field of the error log entry for the 
reason the virtual circuit was closed. This error is normal if the remote system 
crashed or was shut down. 

PORT POWER DOWN 

The Cl port driver: Halts port operations, and then waits for power to return 
to the port hardware. 

User Action: Restore power to the port hardware. 

Note: Powering the Cl port down from the port's power supply box and then up 
while there is any traffic in transit through the port is not supported in 
VAX/VMS Version 4.4; however, CPU and whole system power failures 
are fully supported. 
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PORT POWER UP 

The Cl port driver: Reinitializes the port and restarts port operations. 

User Action: No action needed. 

RECEIVED "CONNECT" WITHOUT PATH-BLOCK 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Submit a Software Performance Report to DIGITAL including 
the error log and a crash dump from the local system. 

REMOTE SYSTEM CONFLICTS WITH KNOWN SYSTEM 

The Cl port driver: The configuration poller discovered a remote system 
with SCSSYSTEMID and/or SCSNODE equal to that of another system to 
which a virtual circuit is already open. 

User Action: Shut the new system down as soon as possible. Reboot it with 
a unique SCSYSTEMID and SCSNODE. Do not leave the new system up any 
longer than necessary. If you are running a VAXcluster and two systems with 
conflicting identity are polling when any other virtual circuit failure takes 
place in the VAXcluster, then systems in the VAXcluster may crash with a 
CLUEXIT bugcheck. 

Note: VAX/VMS Version 3.0 systems are exempt from the SCSNODE 

uniqueness requirement since they all have built-in node names of 
all blanks. Neither can Version 3.0 systems participate in Version 4.4 
style VAXclusters. The purpose of the exemption is to allow customers to 
phase over from Version 3.0 to Version 4.4 style clusters. 

RESPONSE QUEUE REMOVE FAILURE 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. This error is caused by a failure to 
obtain access to an interlocked queue. Possible sources of the problem are Cl 
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300, 
and 8800) contention. 

SCSSYSTEMID MUST BE SET TO NON-ZERO VALUE 

The Cl port driver: Sets the port off line without attempting any retries. 

User Action: Reboot the system with a conversational boot and set the 
SCSSYSTEMID to the correct value. At the same time, check that SCSNODE 
has been set to the correct nonblank value. 

SOFTWARE IS CLOSING "VIRTUAL CIRCUIT" 

The Cl port driver: Closes the virtual circuit to the remote port. 

User Action: Check error log entries for the cause of the virtual circuit 
closure. Faulty transmission or reception on both paths, for example, causes 
this error and may be detected from the one or two previous error log entries 
noting bad paths to this remote node. 
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SOFTWARE SHUTTING DOWN PORT 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Check other error log entries for the possible cause of the port 
reinitialization failure. 

UNEXPECTED INTERRUPT 

The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts, 
it marks the device off line. 

User Action: Call DIGITAL Field Service. 

UNRECOGNIZED "SCA" PACKET 

The Cl port driver: Closes the port-to-port virtual circuit to the remote 
port. If the virtual circuit is already closed, the port driver inhibits datagram 
reception from the remote port. 

User Action: Submit a Software Performance Report to DIGITAL, including 
the error log file that contains this entry and the crash dumps from both the 
local and remote systems. 

VIRTUAL CIRCUIT TIMEOUT 

The Cl port driver: Closes the virtual circuit that the local Cl port opened 
to the remote port. This closure occurs if the remote node is running Cl 
microcode version 7 or later, and the remote node has failed to respond to 
any messages sent by the local node. 

User Action: This error is normal if the remote system halted, crashed, or 
was shut down. This error may mean that the local node's PASTIMOUT 
SYSGEN parameter is set too low, especially if the remote node is running 
privileged user-written software. 


B.7 OPAO Error Messages 

There are a number of error conditions detected by the Cl port driver 
(PADRIVER) which result in an attempt by the driver to log the error 
condition. Under a certain set of circumstances, the attempt to log the error 
to the error logging device will fail. Such failures often happen because the 
error logging device is not accessible, for one reason or another, at the time 
the attempt is made to log the error condition. Because of the central role the 
Cl plays in VAXclusters, the loss of error logged information in such cases 
makes it quite difficult to diagnose and fix problems. 

A second, redundant method of error logging captures at least some of the 
information about Cl error conditions which would otherwise be lost. This 
second method consists of broadcasting selected information about the error 
condition to OPAO, in addition to the port driver's attempt to log the error 
condition to the error logging device. The Cl port driver attempts both OPAO 
error broadcasting and standard error logging under any of the following 
circumstances: 

• The system disk has not yet been mounted. 

• The system disk is undergoing mount verification. 

• During mount verification, it is discovered that the system disk drive 
contains the wrong volume. 
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• The system disk has timed out. 

• The local system is participating in a VAXcluster and quorum has been 
lost. 

Note the implicit assumption that the system and error logging devices are 
one and the same. 

This second method of reporting errors is also not entirely foolproof. Because 
of the manner in which the OPAO error broadcasting must be performed, it is 
possible that some error conditions may not be reported. This situation will 
occur whenever a second error condition is detected before the Cl port driver 
has had a chance to broadcast the first error condition to OPAO. In such a 
case, only the first error condition is reported to OPAO, since it is deemed to 
be the more important one. 

Certain error conditions are always broadcast to OPAO, regardless of whether 
the error logging device is accessible. In general, these are errors that cause 
the port to shut down either permanently or temporarily. 

There is one OPAO error message for each error condition also subjected 
to standard error logging. The text of each error message is similar to 
the summary which would otherwise by displayed by formatting the 
corresponding standard error log entry using Error Log Utility. See 
Section B.6 for a list of the Error Log Utility summary messages and their 
explanations. 

Many of the OPAO error messages contain some optional information such 
as the remote port number. Cl packet information (flags, port operation code, 
response status, and port number fields), or specific Cl port registers. 

Following is a list of each of the OPAO error messages, subdivided by error 
type. The C1780/CI750 User's Guide contains a detailed description of the Cl 
port registers (CNF = Configuration Register; PMC = Port Maintenance and 
Control Register; PSR = Port Status Register), which are optionally displayed 
for certain of the error conditions. The codes, always file accessible, specify 
whether the message is always logged on OPAO or only when the system 
device is inaccessible. 

Software Errors During Initialization (Always Logged on OPAO) 

'/.PAxO, Insufficient Non-Paged Pool for Initialization 

'/.PAxO, Failed to Locate Port Micro-code Image 

'/.PAxO, SCSSYSTEMID has NOT been set to a Non-Zero Value 

Hardware Error (Always Logged on OPAO) 

'/.PAxO, BIIC failure - BICSR/BER/CNF xxxxxxxx/xxxxxxxx/xxxxxxxx 
'/.PAxO, Micro-code Verification Error 

'/.PAxO, Port Transition Failure - CNF/PMC/PSR xxxxxxxx/xxxxxxxx/xxxxxxxx 
'/.PAxO, Port Error Bit(s) Set - CNF/PMC/PSR xxxxxxxx/xxxxxxxx/xxxxxxxx 
'/.PAxO, Port Power Down 
'/.PAxO, Port Power Up 

'/.PAxO, Unexpected Interrupt - CNF/PMC/PSR xxxxxxxx/xxxxxxxx/xxxxxxxx 
'/.PAxO, Cl Port Timeout 

'/.PAxO, Cl port ucode not at required rev level. RAM/PROM rev is xxxx/xxxx 
'/.PAxO, Cl port ucode not at current rev level. RAM/PROM rev is xxxx/xxxx 
'/.PAxO, CPU ucode not at required rev level for Cl activity 
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Queue Interlock Failures (Always Logged on OPAO) 

'/.PAxO, Message Free Queue Remove Failure 

'/.PAxO, Datagram Free Queue Remove Failure 

'/.PAxO, Response Queue Remove Failure 

‘/.PAxO, High Priority Command Queue Insert Failure 

'/.PAxO, Low Priority Command Queue Insert Failure 

'/.PAxO, Message Free Queue Insert Failure 

'/.PAxO, Datagram Free Queue Insert Failure 

Errors Signaled with a Cl Packet 

'/.PAxO, Unrecognized SCA Packet - FLAGS/OPC/STATUS/PORT xx/xx/xx/xx 
(ALWAYS) 

'/.PAxO, Port has Closed Virtual Circuit - REMOTE PORT xxx 
(ALWAYS) 

'/.PAxO, Software Shutting Down Port 
(ALWAYS) 

'/.PAxO, Software is Closing Virtual Circuit - REMOTE PORT xxx 
(ALWAYS) 

'/.PAxO, Received Connect Without Path-Block - FLAGS/OPC/STATUS/PORT xx/xx/xx/xx 
(ALWAYS) 

'/.PAxO, Inappropriate SCA Control Message - FLAGS/OPC/STATUS/PORT xx/xx/xx/xx 
(ALWAYS) 

'/.PAxO, No Path-Block During Virtual Circuit Close - REMOTE PORT xxx 
(ALWAYS) 

'/.PAxO, HSC error Logging Datagram Received - REMOTE PORT xxx 
(INACCESSIBLE) 

'/.PAxO, Remote System Conflicts with Known System - REMOTE PORT xxx 
(ALWAYS) 

'/.PAxO, Virtual Circuit Timeout - REMOTE PORT xxx 
(ALWAYS) 


Cable Change-of-State Notification 


'/.PAxO, Path #0. Has gone from GOOD to BAD - REMOTE PORT xxx 
(INACCESSIBLE) 

'/.PAxO, Path #1. Has gone from GOOD to BAD - REMOTE PORT xxx 
(INACCESSIBLE) 

'/.PAxO, Path #0. Has gone from BAD to GOOD - REMOTE PORT xxx 
(INACCESSIBLE) 

'/.PAxO, Path #1. Has gone from BAD to GOOD - REMOTE PORT xxx 
(INACCESSIBLE) 

'/.PAxO, Cables have gone from UNCROSSED to CROSSED - REMOTE PORT xxx 
(INACCESSIBLE) 

'/.PAxO, Cables have gone from CROSSED to UNCROSSED - REMOTE PORT xxx 


(INACCESSIBLE) 

'/.PAxO, Path #0. Loopback has gone from 
(ALWAYS) 

'/.PAxO, Path #1. Loopback has gone from 
(ALWAYS) 

'/.PAxO, Path #0. Loopback has gone from 
(ALWAYS) 

'/.PAxO, Path #1. Loopback has gone from 
(ALWAYS) 

'/.PAxO, Path #0. Has become working but 
(INACCESSIBLE) 

'/.PAxO, Path #1. Has become working but 
(INACCESSIBLE) 


GOOD to BAD - REMOTE PORT xxx 
GOOD to BAD - REMOTE PORT xxx 
BAD to GOOD - REMOTE PORT xxx 
BAD to GOOD - REMOTE PORT xxx 


CROSSED 

to 

Path 

#1. 

- REMOTE 

PORT xxx 

CROSSED 

to 

Path 

#0. 

- REMOTE 

PORT xxx 
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Two other messages concerning the Cl port appear on OPAO. They are: 

%PAxO, CI port is reinitializing (xxx retries left.) 

'/.PAxO, CI port is going off line. 

The first message indicates that a previous error requiring the port to shut 
down is recoverable and that the port will be reinitialized. The 'xxx retries 
left' is how many more reinitializations are allowed before the port must be 
left permanently off line. Each reinitialization of the port (for reasons other 
than power fail recovery) causes approximately 2K bytes of nonpaged pool to 
be lost. 

The second message indicates that a previous error is not recoverable and the 
port will be left off line. The only way to recover the port in this case is to 
reboot the system. 
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maintaining file* 10-2 
printing file* 10-3 
Error Log Utility* 10-1 
Error report* 10-2 
Exchange Utility (EXCHANGE) 

copying command procedure • 4-14, 4-17 
copying the default bootstrap command 
procedure* 2-19 
Executable image *8-2 


See also Image 
Execution queue *9-1 
Expiration date 
file *7-31 


Explicit 

printing • 9-24 
EXQUOTA privilege *6-1 1 


FIELD account 

initial modification • 5-4 


Generic queue *9-2 
GROUP privilege*6-8, 6-11 
GRPNAM privilege *6-12 
GRPPRV privilege *6-12 



Hardware problem 
reporting *4-18 
Header resident image *8-1 


i 


Image 

attributes* 8-1 
executable• 8-2, 8-3 
execute-only • 8-3 
file *8-4 

header resident *8-1 
known • 8-1 
linkable* 8-2 
privileged • 8-3 
shareable*8-2, 8-3 
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Image operation*7-16, 7-23 
copy• 7-16 
restore *7-16 
save* 7-18 
Implicit 

printing • 9-24 

Incremental backup *7-22 to 7-23 
INITIALIZE/QUEUE command *9-6 
INITIALIZE command *7-3 
Install Utility (INSTALL) • 8-1 


Known file list*8-1 
privileges* 8-3 
startup procedure*8-1 
Known image*8-1 
deleting *8-4 
dismounting volume *8-4 
site-specific startup *2-8 


L 


Limit (cont'd.) 

direct I/O count *6-3 
enqueue quota *6-4 
open file *6-4 
paging file *6-5 
process jobs *6-5 
shared file*6-5 
subprocess creation *6-5 
system resources*6-1 
timer queue entry *6-6 
working set default size *6-6 
working set extent *6-6 
working set quota • 6-6 
Limits and quotas *6-1 to 6-6 
Linkable image *8-2 
List operation (BACKUP) 
using wildcard • 7-29 
LOAD command* 11-11 
Log file 

accounting *6-19 
Logical name 

assigning systemwide*2-6 
Logical queue *9-3, 9-43 
assigning *9-43 
deassigning *9-43 
Login 

restricting by function • 5-20 
restricting by time *5-19 
setting AUTOLOGIN flag *5-20 
Login command procedure*5-7 
alternate* 5-21 
individual *5-7 
systemwide* 5-7 
user-specified* 5-7 
Login procedure 

system manager's account *2-2 
Login sequence*5-20 
LOGIO privilege *6-12 
Logout command procedure • 5-10 
Lost file 

recovering* 5-17 



JBCSYSQUE.DAT *9-4 
JOB card • 9-53 
Job controller*9-3 
Job queue 

small-disk systems *3-12 
Job queue manager 
restarting • 9-5 
starting *9-4 

Job separation pages *9-32 to 9-36 
Job table quota *6-4 
Journal file*7-24 


K 


LAT terminal* 11-14 
Library 

See Device control library 
Limit 

account jobs*6-4 
AST queue *6-2 
CPU time*6-3 
DEFAULT account *5-1 1 
detached process *6-5 



MA780 multiport memory 
installing shared images *8-5 
Machine-readable file 

for software performance report* 10-10 
Magnetic tape 

restoring save set 
•7-25 
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Magnetic tape (cont'd.) 
write ring • 7-8 

Maximum account jobs limit *6-4 
Maximum detached process limit *6-5 
Maximum process jobs limit *6-5 
Media security 

Backup Utility • 7-23 
Merge 

output queues*9-8 
Message 

operator log file* 10-3 
Module 

device control library *9-25 
Monthly backup *7-23 
MOUNT/BIND command *7-2 
MOUNT/SYSTEM command *7-5 
Mounting volume 

operator assistance*7-6 
MOUNT privilege *6-13 
Mount verification • 7-9 
abort by dismount • 7-13 
canceling • 7-11, 7-12 
device offline*7-9 
device write lock *7-10 
MSCP server 

loading and starting* 11-19 
Multiport memory 

SYSGEN commands* 11-17 
MVTIMEOUT system parameter*7-11 


N 


NETMBX privilege *6-13 
Network Control Program (NCP)*5-24 
Network UAF 
creating • 5-22 
Node name 

for dual-ported disks *4-15, 4-17 
Node number 

specifying for HSC boot *4-13 
Normal privilege • 6-8 


o 


OPCOM (operator communication facility)* 10-3, 
10-5 

restarting • 10-7 
OPCOM message 

enabling an operator terminal* 10-7 


OPCOM message (cont'd.) 
mount request *7-7 
request display* 10-7 
Open file limit *6-4 
Operating system 

adding to an existing system disk *2-27 
building on another disk *2-25 
components* 1-3 
copying files to another disk *2-26 
directories* 1-3 
Operator 
tasks* 1-2 
terminal* 1-1 

Operator function* 10-3 to 10-6 

handling user request *7-6, 7-7, 10-7 
Operator log file* 10-3 
example* 10-4 
maintaining • 10-6 
message* 10-3 
printing • 10-6 
purging • 2-8 
Operator terminal 
setting up* 10-7 
user request* 10-7 
OPER privilege *6-13 
Output queue 

control commands *9-5 
defining form *9-30 
deleting • 9-8 
establishing* 9-22 
merging • 9-8 
pausing *9-7 
stopping *9-7 
Output spooling • 9-46 


p 


Paging file* 11-15, 11-16 

use in small-disk dump *3-13 
Paging file limit • 6-5 
Paper stock 

specifying • 9-30, 9-41 
Parameter file 
creating* 11-10 
Password 

modifying system • 5-4 
modifying user *5-5 
secondary • 5-5 
PASSWORD card *9-53 
PFNMAP privilege *6-13 
PHY_IO privilege *6-14 
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PRIMARY day 
defining *5-19 

PRINT command • 9-24, 9-32, 9-42 
Print control features 
assigning • 9-32 
Printer 

controlling functions • 9-25 
setting characteristics • 2-7 
spooled • 9-24 
Print job *9-1 

aligning forms *9-15 
controlling • 9-10 
deleting *9-12 
explicit printing • 9-24 
implicit printing • 9-24 
requeuing *9-13 
retaining* 9-13 
Priority 
base* 6-7 
Privilege 
all *6-8 
devour* 6-8 
file *6-8 

known file lists*8-3 
process* 6-7 
summary • 6-8 
system • 6-8 

system management* 1-3 
Privileged image *8-1 
PRMCEB privilege*6-14 
PRMGBL privilege • 6-14 
PRMMBX privilege *6-15 
Process priority *6-7 
Process privilege*6-7 
Proxy 

adding accounts*5-23 
controlling system use *5-24 
PSWAPM privilege *6-15 
Public disk 

copying with Backup Utility *7-16 
Public files and volumes *7-1 
Public file structure • 7-1 
Public volume 

backing up* 7-14 
mounting • 2-6, 7-5 


Queue (cont'd.) 
batch *9-18 
command 

DEFINE/FORM *9-31, 9-42 
DELETE/QUEUE *9-8 
INITIALIZE/QUEUE *9-6, 9-42 
SET QUEUE *9-7, 9-42 
START/QUEUE *9-6, 9-42 
START/QUEUE/MANAGER *9-3, 9-5 
STOP/QUEUE *9-7 
STOP/QUEUE/MANAGER • 9-4 
STOP/QUEUE/NEXT • 9-7 
STOP/QUEUE/RESET • 9-7 
creating • 9-6 

creating new queue file *9-5 
defining forms *9-30 
deleting a job *9-12 
deleting a queue *9-8 
execution • 9-1 
generic batch *9-2 
generic output *9-2 
initializing • 2-7, 9-6 
job queue manager *9-3 
logical • 9-3 
merging *9-8 
modifying • 9-7 
output • 9-22 
pausing • 9-7 
protecting *9-9 
restarting • 9-8 

specifying attributes*9-32, 9-37 
specifying characteristics • 9-29 
starting *9-6 
stopping *9-7 
types *9-1 
Queue file 

creating new *9-4 
Queue Manager 

See Job queue manager 
Quota 

disk *7-32 

jobwide logical name table *6-4 


R 



Queue* 9-1 

assigning device control libraries • 9-27 


READALL privilege • 6-15 
Real-time priority *6-7 
REPLY command 

/DISABLE qualifier* 10-7 
/ENABLE qualifier* 10-7 
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Reporting problem *4-18, 4-19 
REQUEST command 
/REPLY qualifier* 10-7 
/TO qualifier* 10-7 
Reset sequence *9-34 
Resource 
limit *6-1 
Restart 

job controller*9-3 
Restore operation • 7-25 to 7-31 
Rotating backup set *7-15 
Running system 
modifying *11-11 


s 


Save operation (BACKUP) 

saving full volumes and volume sets *7-16 
Save set 

listing contents* 7-28 
restoring • 7-25 
sequential-disk *7-19 
writing multivolume* 7-20 
SCS (system communications services) • B-1 
SECONDARY day 
defining* 5-19 
SECURITY privilege *6-15 
Selective backup *7-21 to 7-22 
using creation date *7-21 
using expiration date *7-21 
using the /EXCLUDE qualifier*7-22 
using UIC*7-21 
using wildcards* 7-21 
Separation pages 
file *9-37 to 9-41 
job*9-32 to 9-36 
SET/STARTUP command* 1 1-17 
SET HOST/HSC command* 11-12 
SETPRV privilege *6-16 
SET QUEUE command *9-7 
Shareable image *8-2 
See also Image 
file *8-4 

with MA780 multiport memory *8-5 
SHARE command* 11-17 
guidelines* 11-18 
Shared files limit *6-5 
Shared memory 

SYSGEN commands* 11-17 
SHARE privilege • 6-16 


SHMEM privilege*6-16 
SHOW/STARTUP command* 11-17 
Shutdown 

by forced system failure *4-6 
emergency *4-5 
site-specific *4-1 
system • 4-1 

SHUTDOWN.COM procedure*2-14 
Shutdown procedure • 2-20 
Site-specific startup *2-5 
announcements • 2-9 
assigning logical names *2-6 
installing known images *2-8 
setting up queues *2-7 
setting up spooled devices *2-7 
Small-disk system • 3-1 

analyzing system failure *3-13 
enabling job queue *3-12 
installed file *3-14 
Software performance report 
See SPR 

Software problem 

reporting *4-19, 10-8 
Spooled device *9-24, 9-46 to 9-52 
SPR (software performance report)* 10-8 
classes of problems* 10-11 
describing problem environment* 10-8 
what to include* 10-11 
STABACKIT.COM procedure • 2-19 
Standalone BACKUP *2-18 

alternate disk directory root *2-19 
backing up the system disk *2-18 
booting from alternate root SYSE*2-19 
building on console media *2-21 
building on floppy diskettes*2-21 
installing in SYSE*2-19 

START/QUEUE/MANAGER command *9-3, 9-5 
START/QUEUE command *9-6 
STARTUP.COM procedure • 2-3 
Startup command procedure • 2-3 
known file lists • 8-1 
site-specific* 2-5 
SYSGEN commands* 11-17 
system *4-1 

STOP/QUEUE/MANAGER command *9-4 
STOP/QUEUE/NEXT command *9-7 
STOP/QUEUE command *9-7 
Subprocess creation limit *6-5 
Swap file* 11-15, 11-16 
SWAPFILES.COM procedure* 11-15 
Symbiont *9-1 to 9-2, 9-7 
identifying process *9-3 
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SYS$ANNOUNCE logical name*2-9 
SYS$WELCOME logical name *2-10 
SYSBOOT program 

alternate conversational bootstrap*4-11 
alternate nonstop bootstrap *4-10 
commands *4-11 
default bootstrap *4-10 
SYSE 

booting standalone BACKUP *2-19 
SYSGBL privilege *6-16 
SYSGEN 

AUTOCONFIGURE command *2-4 
invoking *4-16 

SYSHUTDWN.COM procedure *4-1 
SYSLCK privilege *6-16 
SYSNAM privilege *6-17 
SYSPRV privilege *6-17 
SYSTARTUP.COM procedure • 2-5 
operator-assisted mount *7-5 
System 

accounting *6-19 
directories* 1-3 
disk fragmentation* 11-15 
errors* 10-1 
events* 10-1 
shutdown *4-1 
startup *4-1 
SYSTEM account 

initial modification • 5-4 
user authorization file entry *5-3 
System communications services 
See SCS 

System disk*7-3 
System Dump Analyzer (SDA) 
site-specific startup • 2-8 
System failure 
forced • 4-6 
reporting • 10-8 
system dump analyzer *2-8 
System file 

manipulating* 11-8 
size* 11-15 

System generation* 11-1 
System Generation Utility (SYSGEN)* 11-9 
invoking *4-14 

WRITE ACTIVE command* 11-11 
System parameter 
dynamic* 11-11 
modifying • 11-9, 11-10 
MVTIMEOUT *7-1 1 
used at bootstrap time* 11-9 


System process 
OPCOM* 10-5 
System security 

backup media *7-23 
System shutdown procedure • 2-20 
SYSTEST account 

initial modification • 5-4 

user authorization file entry *5-3 


T 


Tailored system 

preparing for UETP*3-11 
Tailoring command *3-4 
COPY *3-5 
DELETE *3-6 
DIRECTORY *3-7 
DISMOUNT *3-8 
EXIT *3-8 
HELP *3-8 
MOUNT *3-9 
RECORD *3-9 
SEARCH *3-10 
Tailoring facility 

creating site-specific file group *3-3 
file group description • 3-1 
issuing commands *3-4 
Tape volume 
accessing • 7-6 
Terminal 

console* 1-2 
determining type* 11-14 
LAT* 11-14 
operator* 1-1 

setting characteristics*2-7 
site-specific startup *2-7 
virtual 

See also Virtual terminal 
Timer queue entry limit *6-6 
TMPMBX privilege *6-17 
Trailer page*9-32 
Translation modes 
card reader *9-54 
TU58 cartridge 

write protection *2-17 
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UAF (user authorization file) 
creating network *5-22 
general maintenance*5-3 
initial contents*5-3 
initial modification • 5-4 
login check*5-20 
privileges* 6-8 
resource limits *6-1 
user priorities*6-7 
UAF record 

creating multiple default *5-15 
UETP (User Environment Test Package) 
preparation in tailored system *3-11 
UIC (user identification code) 
in selective backups *7-21 
Unit address 

specifying for HSC boot *4-13 
User account 
deleting *5-15 
disabling *5-17 
maintaining* 5-14 
restricting use *5-18 
setting up*5-3 
User authorization file 
See UAF 
User file 

placement • 7-2 
User resources *6-1 
Utility 

system management summary* 1-3 


Volume 

backing up full volumes and volume set *7-16 
mounting* 7-6 
Volume integrity • 7-8 
Volume set *7-2, 7-3, 7-20 


w 


Weekly backup *7-23 
Wildcard character 

in selective backup operation • 7-21 
Working set 

default size • 6-6 
extent *6-6 
quota *6-6 

WORLD privilege*6-18 
Writeboot Utility (WRITEBOOT) • A-6 
Write lock 

mount verification • 7-10 



Verification 
mount* 7-9 
Verify Utility (VERIFY) 

Recovering lost files *5-17 
Virtual circuit*B-1 
Virtual terminal *11-12 

VMSKITBLD.COM procedure • 2-24, 2-25, 2-26, 
2-27 

VMSTAILOR facility 
See Tailoring facility 
VOLPRO privilege *6-18 
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